Hi,
i used hutch bin2db tool and converted a 4096 byte file to db's .
I declared it as follows:

.data
Mydata db 142,217,41,223,119,123,25,118,26,231,104,29,17,112,224,233
db 250,198,12,28,29,199,19,225,232,81,70,108,92,195,59,67
db ... blah

so its 4096 bytes.

when i try to access the array it doesnt seem to work. it seems that most of it is missing or something. its screewed!

Am i doing anything wrong? is the above declaration incorrect!?

any help appreciated.
Posted on 2002-08-16 13:52:44 by Ray
Hi Ray

It seem OK to me.
How are you accessing the array?

KetilO
Posted on 2002-08-16 14:00:12 by KetilO
Hi,

I am just playing around with it trying to make it work. But what i do is just :

lea eax, MyData
int 3 ; <<-- Break here

and then have a look from my debugger at eax .

Most of the values are missing! it seems that it allocates a few bytes with the correct values and then all the rest with ?????????????????????????????????????????????????????????????

any ideas?
Posted on 2002-08-16 19:47:54 by Ray
If your data crosses a page boundary, that could be the "problem". If you're using softice, try playing with the "pagein" command (original pagein, not the early-version icedump extensions).
Posted on 2002-08-16 21:04:34 by f0dder
Ray,

its finally just DB data so you can use it in the .DATA section by putting a name before it like any other byte data.

MyData \
db numbers etc ...

Then use OFFSET when you load the address.

mov eax, offset MyData

It is up to you to control how many bytes you read from the data section.

You can also use it from the code section by placing a label in front of the DB data.

MyData:
db numbers etc ...

Just make sure you do not try and EXEcute data stored in the code section or it will crash big time. Normally you jump over it.

Regards,

hutch@movsd.com
Posted on 2002-08-17 06:11:33 by hutch--
Heya guys,
fodder was right. I used pagein and lo and behold, there they are! fodder, whats the thing with pagein anyway?

hutch: it turned out that my declarations where right. i threw all thoses db's in my data section. in your opinion which is better? have them in data section or in code section and jmp over them??

:alright:
Posted on 2002-08-17 08:56:04 by Ray
Ray, PE exeuctables are demand-loaded. That's why a (uncompressed!) 200meg executable will load just as fast as a 4k one (until data/code is accessed, of course). Before a page is accessed, it's in "uncommitted" state, and will be shown as ?????????. Softice pagein performs a, geeeh, "pagein" command :), to bring in a page from the executable file.
Posted on 2002-08-17 09:13:19 by f0dder
Thanks for clearing things up F0dder
:cool:
Posted on 2002-08-17 13:44:12 by Ray

That's why a (uncompressed!) 200meg executable will load just as fast as a 4k one


VB applications load as fast as assembly programs?



*SCNR*
Posted on 2002-08-17 14:09:45 by bazik

VB applications load as fast as assembly programs?

Well, that depends... all executables are treated equally. But most VB executables will probably end up pulling in more DLLs than other apps. Besides, VB apps will run a good deal of runtimes before executing "your" code. 0CCH is not the ultimate truth ;)
Posted on 2002-08-17 18:31:49 by f0dder
This has to be crap, test a 4k assembler program against netscape, M$ Word/Excel/Access, embed the data into the code section and die laughing.

Anything that is large occupies more disk sectors so it will take longer to load, no matter if it is code OR data.

Theoretical load times based on demand paging do not have a corresponding real world example to go with them, watch Netscape load and it has to load both code and data, numerous DLLs etc .... and its slow because its large.

More BYTES = MORE work
Therefore
Longer loading time.

You worry me at times f0dder. :tongue:

Regards,

hutch@movsd.com
Posted on 2002-08-18 03:09:48 by hutch--
You don't get it, do you hutch? Or are you just ignoring what I write?
Two executables, if using the same DLLs, will load at the same speed no matter what exe size or language it's written in. Of course the speed until the interface/whatever is up will depend on runtimes and such - and here you'll be able to see the difference between VB, delphi, BCB, MFC, asm, *whatever*. But the *load* time of the module (if uncompressed) doesn't depend on exe size - just the DLLs used.

Netscape obviously has a hell of a lot more DLLs than any program you have ever written, more code than you will ever write, and the same (or more) bloat as any microsoft app.

Oh, and I can easily write a 200meg exe that'll load just as fast as any 4k assembler app...
Posted on 2002-08-18 03:25:57 by f0dder
f0dder,

are you trying to pull my leg ?

Ray, PE exeuctables are demand-loaded. That's why a (uncompressed!) 200meg executable will load just as fast as a 4k one (until data/code is accessed, of course). Before a page is accessed, it's in "uncommitted" state, and will be shown as ?????????. Softice pagein performs a, geeeh, "pagein" command , to bring in a page from the executable file.

You have not mentioned a DLL here, just PE executable and this entails EXE files as well as DLL files. a 1k EXE loads faster that a 1 meg exe, no matter what and this is before and DLL is loaded.

Now you may be able to write a 1k front end that loads DLL files later (delayed load etc ...) that loads as fast as a normal 1k executable but you get nothing for nothing, if your prog must load extra stuff, it take time to do it.

Have you been playing with recreational chemicals ?

Ray,

It does not really matter which you use, as long as you are comfortable with the technique you are using, probably the only advantage with placing the data in the .DATA section is that you can both read and write to the data.

Regards,

hutch@movsd.com
Posted on 2002-08-18 10:01:12 by hutch--
*sigh*, here we go again.

Let's see if I can explain this so thoroughly that even hutch has a chance of understanding what I mean.

By "loading time", I mean from the Process is Created (like, double-clicking it in explorer), until the entrypoint is reached (in case of compressed images, the original entrypoint). This loading time *is* shorter for uncompressed images, as they only have to pagein() a few pages, whereas compressed images obviously must have the entire contents paged in, during the decopmression stage.

This time is, of course, also affected by the implicitly loaded DLLs. This will be only really be noticeable if an application relies on DLLs that aren't already present in memory (like delphi/BCB runtimes), and even moreso if those DLLs are compressed.

However, none of this is related to "a 200meg executable loads just as fast as a 4k executable", but I felt it was necessary to include to show what I mean by 'load'. Oh, there might be some tiny speed difference between 4k and 200meg, as a larger memory range will have to be reserved (reserved, NOT committed), but this should hardly be more than a few milisecs, if that much.

Of course a large exe with runtimes and lots of implicitly loaded DLLs will take a longer time to present its GUI than something smallish written in asm - but that's not related to the load-time I'm talking about.


Have you been playing with recreational chemicals ?

Other than alcohol, no. And I honestly don't see what that has to do with anything; I have my facts straight (at least in this thread).

I hope any possible misunderstandings have been straightened out now. Otherwise: STFU, GFY, and whatever other funny abbreviations you can think of.
Posted on 2002-08-18 10:32:01 by f0dder
What f0dder seems to mean is that the time from when you click to load a file (from explorer or some other shell) till you reach the entrypoint specified in the PE header is the same no matter the size of the file. All it depends on is the amount of dll's it must load before reaching the entrypoint.

I think placing your data as code is not recommended unless you specificly need it. I think it's bad programming practice to mix it although I do it myself in one project and the only reason for doing it is that I want to have one PE section in my file so I have no other choise. However as hutch points out you can only read the data unless you adjust the linker settings.

// CyberHeg
Posted on 2002-08-18 10:32:22 by CyberHeg
OK,

So if I have it right, you are arguing that "load" means a program reaching the entry point of the written part of the program (differing from the section loading etc ...)

This is perhaps the diference between our views, I see LOAD as meaning how long it takes for the program to be up and running so that the user can USE it.

Now if your view means the time it takes to get from the MZ header to the program entry point, I guess you are talking about something else apart from the loading time of a program. Its just that it did not follow from your first posting where you used LOAD in a manner that is different to how its usually understood.

-----------
Other than alcohol, no.
-----------

That will do I guess. :tongue:

Regards,

hutch@movsd.com
Posted on 2002-08-18 22:00:16 by hutch--

This is perhaps the diference between our views, I see LOAD as meaning how long it takes for the program to be up and running so that the user can USE it.

And again, this doesn't directly have to do with EXE size; it does have to do with the code path taken, and included DLLs. You could easily add 200 megabytes worth of resources to a 4k exe, and it would load just as fast (as long as it's not compressed).


Now if your view means the time it takes to get from the MZ header to the program entry point, I guess you are talking about something else apart from the loading time of a program.

Not really. The program (or, to be pedantic, image) is loaded when you reach the entrypoint (or in case of compressed image, original entrypoint). Runtime library initialization and GUI setup of course have to be done before the program is in a usable state ("user loaded" ;)).

And after all, I did put it as

That's why a (uncompressed!) 200meg executable will load just as fast as a 4k one (until data/code is accessed, of course).


and


But most VB executables will probably end up pulling in more DLLs than other apps. Besides, VB apps will run a good deal of runtimes before executing "your" code.


So there's no justification whatsoever for your "This has to be crap,", I am clear and correct in my statements.

Now you may argue that I'm pedantic, and that's not enritely incorrect. However, I do feel it's important that people understand how demand-loading works (as one of the reasons why you shouldn't compress your apps unless you have a specific reason to do so). Also, not necessarily all resources have to be used right at program start, so this isn't a totally theoretical point.
Posted on 2002-08-19 09:40:10 by f0dder
Hutch, fodder,

so let me see if i get this right:

I have :
(1) An exe with 4k code segment : 4k data segment
(2) An exe with 4k code segment : 200mb data segment.
Both programs have the EXACT same code in Code segment, for example they just display a msgbox and exit.
So, these 2 programs will require the same time to load and the same time to execute correct? even though the (2) exe has 200mb of crap data(but never used!)? correct?
In this case the actual 200mb of data is never loaded, but only the memory is reserved in case that the data is DEMANDED to be loaded! correct?

lets move on now,
I have
(1) An exe with 4k code segment : 4k data segment
(2) An exe with 4k code segment : 200mb data segment.
Now, program (2) has lets say an AVI of 200mb which just displays it in a window. Program (1) displays just a msgbox.
According to what you guys say, both programs will require the same time to reach the ENTRY POINT but then each one goes its own way? correct?

i hope iam clear.
Posted on 2002-08-20 07:22:00 by Ray
Exactly, ray.
Unless of course the executables are compressed, then the matter is different (long live filesystem compression which doesn't have the flaws of executable compression).
Posted on 2002-08-20 08:45:54 by f0dder
The distance in byte count from the start of the MZ header to the program entry point has little to do with the load time of a program, it is technically possible to write a program that does no more than start up a message box or similar and wait for user input before it loads the rest but no matter what, if its bigger overall, it takes longer to load.

i have taken you to task on the idea that all programs load in much the same time, its you notiuon of load that is defective and it seems it is why you made the nonsense statement below.

That's why a (uncompressed!) 200meg executable will load just as fast as a 4k one (until data/code is accessed, of course). Before a page is accessed, it's in "uncommitted" state, and will be shown as ?????????.

Your notion of LOAD is unrelated to what is the normal event when a user starts a program, from clicking on it to when its up and ready to use is the normal use of LOAD TIME, not the beginning of the entry point.

You could redefine the notion of LOAD as completing the dos EXE signature, that is, reading 2 bytes MZ as the LOAD time but it would be as unrealistic as the technique you are using to define load time.

I wonder how this nonsense handles things like DOS programs or dos COM files or 16 bit NE or LE programs that don't have the same EXE structure ? Do they LOAD in a different way to get the load time ?

I call crap, crap and thats how I see the statement you made, something unrelated to the way programs are started.

Regards,

hutch@movsd.com
Posted on 2002-08-20 09:08:02 by hutch--