Here's the steps to convert from section alignment to file alignment:
Find the RVA for the data
From the RVA, derive the section to which the data referenced belongs. This is trivial, since sections don’t overlap. The starting addresses of the various sections are available in the file header
Find the difference between the RVA and the starting address of the section to find the data offset, ie, offset of that data within a section.
From the file header, for the same section, find the location of the same section in the file.
Add the data offset to the location of section in the file, to find the address of the data in the file.
But I just don't understand that, can someone elaborate with more details?
Alignment is a rounded up value. Section data size is rounded up for effeciency because the OS moves stuff around in chunks anyway.
The File Alignment is usually 512 bytes which fit the blocksize of most filesystems.
The Section Alignment is usually 4096 bytes which fit the size of a memory page.
So if you have a PE-file with a section (like ".text") that contains 513 bytes of data:
Section .text will be rounded up to 1024 bytes on file.
Section .text will be rounded up to 4096 bytes in memory.
Note the amount of slack space possible both on file and in memory.
I'm unsure about why you want to "convert from one alignment to the other". The recipe you got there leaves the goal of the exercise as a mystery. If your goal is to manipulate PE-files then all you have to consider is the File Alignment. The Windows loader will handle the Section Alignment stuff when it throws it into memory, so you usually don't need to think about that at all.
You can read more about PE here.
Related
I have a typedef structure containing the YUV components that I took from a video frame.
I need to find a way to write these YUV components into a (.YUV) file extension so I could use it for my application in C language.
Does anyone know, How can I can do it?
Best Regards
Well, one of the more common yuv-formats (or rather YCbCr) is YV12
Its is also known as plane-separated 4:2:0 8bpp. Where the 4:2:0 denoted the subsampling used for the color components. 8bpp means the valid range is [0-255] (not realy true, but lets not go there right now...)
It consists of width x height bytes luma-samples (the Y-part) followed by width x height / 4 Cb-data and the same amount of Cr-data. Total number of bytes for one frame is width x height * 3 / 2
So basically all you need to do is to write the Y-component as uint8, followed by Cb-data and Cr-data.
If you need some example code in c to look at, check my yuv-viewer on github.
Hope it helps, if not, drop me a comment.
You will need to learn how to write to a file in binary mode. Take a look at these examples. Once that is clear, all you need to do is dump the hex values of the YUV channels into file.
Description of Application:
I have an application that allows a user to output a report to a document. The data that is written to the document is in the form of a table. The number of columns in the table and the width of the strings contained in each cell in the table are unknown until runtime (it depends on what query the user runs, what they want to see in the report etc.).
I'm using Delphi XE and Gnostice's eDocEngine to create a PDF document, and then creating a table in the document and writing the report data into it.
Problem:
The problem that I'm having is that you can only write a certain number of columns (6 or 7) into the document before they disappear off the right hand side of the document. It isn't unknown for a user to produce a report with 30 or 40 columns in the table (as they correspond to fields in a database, which they run a query over), so I need to be able to get the table to fit entirely into the document, no matter how many columns it contains.
As a PDF can be zoomed, I suppose I could shrink the font size and column widths down and fit everything in that way, as the user could then zoom in and scroll around the table using their PDF reader. What I need to know is:
Is there a better way of getting the entire table to fit onto a page?
If shrinking/zooming is the best/only way of doing this, what is the most efficient way of ensuring that everything fits without making the document look strange (i.e. the table should ideally stretch across the page, rather than be bunched up to the left hand side because of some random scaling algorithm).
Edit
I've just done some more digging around and I've found "inputXRes" and "inputYRes" properties that change the scale of the canvas in the document, which looks promising, but I can't get it to work properly at the moment. Can anyone shed any light on how those properties are used? The text itself is scaling, but the size of the table stays the same, meaning that I've now got a tiny piece of text in the middle of a huge table cell, and the table is still only displaying 7 columns in the report.
Don't mess with scaling and font size.
Your customers will use PDF Reader and there are some options that will help to read the informations e.g. 1:1. But when you change the scaling or font size you cannot read the information, because it is too small.
Get a font size that fits perfect the needs of your customers and extend the page size to fit the table size.
With PDF Reader your customers will have the choice to view and print (shrink to fit) as they like and which paper size their print can handle.
BTW:
If you change the resolution and draw a line with a length of 2 inch on the canvas it will be 2 inch long, but a text with font size 12 (pixels) will grow or shrink.
In Delphi 7 IDE, do the lines need to be a given length? I see a gray line in some Delphi code I'm working with, and it looks like ever line ends right before it.
It's called the right margin. It is intended as a guide to help you avoid writing lines that are too long and exceed your coding standards. You can switch it off from the Editor Options, as I have done here:
It's just a guide to line length. Some people don't like long lines because they can be hard to read on different resolutions or when doing comparisons.
That gray line is called the margin.
You can set its visibility and position in the Editor Properties at the Display tab in the Margin and gutter groupbox.
The margin is a visual assistent. The standard position is 80 characters, which defaults to the maximum unscrolled size of many source formatting output media, such as the one used here at Stack Overflow. Originally, it had something to do with the paper width on (matrix) printers. Maybe it still does.
I am having some issues with the TRichEdit.
The first issue is if I try to paste a lot of text from the clipboard into a empty TRichEdit, it truncates the bottom of the text.
The second issue, which I guess ties into the first issue, is that I seem to be limited to how many characters the TRichEdit can display, hence pasting from the clipboard is losing some of the data.
If I paste into a TJvRichEdit (Jedi), that works fine, obviously because that is a completely different component.
At this moment in time I would like a solution for the TRichEdit because I am using a lot of procedures/functions etc, if I change to a different Rich Edit class then I will have to edit a lot of my code to work.
So basically what I am asking is:
Is there a limit in the TRichEdit? which I am sure there is.
How can I increase the limit of the TRichEdit to accept more characters and lines etc.
Please provide advice/solution for TRichEdit only.
EDIT
never mind found the answer using:
RichEdit11.MaxLength := $7FFFFFF0;
Quoting an answer given by David Pate from the newsgroups:
The following remarks apply to the versions of Delphi that use the Windows Richedit version 1 control. I understand that this includes all Delphi versions prior to version 7. (I do not know what the situation is when you run programs compiled in these versions on the various NT/2000 versions of Windows although Windows XP behaves as described.)
Q. What is the limit to the amount of text that a Richedit can hold? A. The help files (Delphi help and Win32 SDK) are confusing, contradictory and incorrect on this point. There are 5 limits to be considered
The Maximum Capacity: the "hard-wired" limit, i.e the maximum size of the RichEdit's text buffer. It is 2 bytes less than 2 Gb. Note that this is the theoretical limit; in practice the limit will be determined by your computer's memory.
The Capacity: the actual size of the current buffer. By default, it is 64Kb but can be resized by several means.
The "Keyboard limit": the limit beyond which characters cannot be added by typing from the keyboard. It is often different from the Capacity but, like the Capacity, it is by default, 64Kb and can be resized by several means.
The MaxLength property of the tRichEdit object. The default of 0 sets both the Capacity and "Keyboard limit" to 64Kb.
The line-number limit: theoretically this is around 134 million, but in practice, you can expect to get much less than this. The maximum number of lines seems to depend on several factors including the amount of memory available and the average length of the lines. I find that I can get around 150 thousand to 200 thousand lines. Note also that it has been reported that some releases of the Windows 95 Richedit control sometimes throw an exception when more than a few hundred lines are added. This appears to be due to a bug in the control and to have been corrected in later releases..
Q. How can I increase the amount of text that a tRichEdit can hold?
A. When you add text programmatically, both the Capacity and the "Keyboard limit" are resized to accommodate the text being added. By adding text programmatically, I mean using any of the Add, Append, AddStrings or Assign methods of the tRichEdit.Lines property or the LoadFromFile, LoadFromStream or SetTextBuf methods of tRichEdit. Note that adding text in this way does not update the MaxLength property.
B. By using the MaxLength property. This sets the "Keyboard limit" to the value passed to MaxLength. It also increases the Capacity to match the "Keyboard limit" if the existing Capacity is less than MaxLength. Note that you cannot use MaxLength to reduce the Capacity and that changing MaxLength has no effect if the value passed is less than the length of the text currently in the control. To increase the Capacity and the "Keyboard limit" to the same value, set the tRichEdit.MaxLength to the desired value. To set the maximum size in the Object Inspector, use the value 2147483645 ($7FFFFFFD). To set it programmatically it is simpler to use .MaxLength := System.MaxInt-2;. The EM_LIMITTEXT and EM_EXLIMITTEXT messages may also be used to change the "Keyboard limit" and Capacity but I'd not normally recommend using them since, if you do, you will not be updating the MaxLength property.
I have a LOGFONT structure. Now all i'd like to do is get the associated font size in points from the LOGFONT height.
When the mapping mode is mm_Text (which it usually is), and when the lfHeight field is positive, it already gives the height in points. When it's negative, the units are pixels. MSDN for LogFont gives you the formula to convert between them:
lfHeight = -MulDiv(PointSize, GetDeviceCaps(hDC, LOGPIXELSY), 72);
There are 72 points per inch. GetDeviceCaps tells you the number of pixels per inch on a given device. Invert the formula to get pixels from points:
PointSize := MulDiv(-lfHeight, 72, GetDeviceCaps(hDC, LogPixelsY);
The important thing to realize here is that you need a device context. Font sizes don't exist independently of the media they appear on. The pixel height of a font on the screen will be different from the pixel height of a font on a printer. Use the Handle property of whatever canvas you're planning on drawing to.
I find this a bit confusing, as well.
Here are a few things that I háve learned. ;)
Examine the two low-order bits of lfPitchAndFamily to determine the font type.
For fixed-pitch fonts, use GetTextMetrics and the TEXTMETRIC structure.
For variable-pitch fonts (true-type, etc), use GetOutlineTextMetrics and the OUTLINETEXTMETRIC structure. Be sure you have the structure aligned properly. Also, the structure is variable-sized. Call the function once to get the size, allocate space, then call the function again to fill the structure.
From there, you can find proper ascent, descent, and other size-related information.
Keep in mind that they are recommended values and not all display routines will use them properly. For example, I am in the process of figuring out a correct method of determining the required height of a dialog box static control for a given string of text.
It does not appear that Microsoft has followed their own documentation. ;)
Not that the documentation is all that clear or complete, to begin with.