Index
> Compiler Internals > Error 200 - BUG with FASM's "format MZ"Goto page Previous 1, 2 |
| Author |
|
... about breaking compatibility by "next version of windows" , that's what all previous versions already did ... so no breaking news pending 
|
DOS386 11 Jul 2008, 12:38
revolution wrote:
Code:
USHORT e_csum; // Checksum
I've not yet seen a MZ executable having a "checksum" different from 0, so either: - all coincidence - unique "checksum" algo always returning 0 (but still very useful  )
or - the "MZ header format" posted by you (where did you get it from ?) can't be taken too seriously  |
|||
11 Jul 2008, 12:38 |
|
|
revolution 11 Jul 2008, 12:43
DOS386 wrote: Not my fault. After all, ... DOS386 wrote: ... I didn't ask for deleting the code enhancing the header, just adding an option, so your $40-bytes headers are 100% safe DOS386 wrote: ... about breaking compatibility by "next version of windows" , that's what all previous versions already did ... so no breaking news pending DOS386 wrote: ... , and, finally, this forum is full of complaints about virii in FASM itself or the examples, so even Tomasz is unable to brew a 100% safe executable, and, not sure who is then, if anyone at all |
|||
|
11 Jul 2008, 12:43 |
|
|
revolution 11 Jul 2008, 12:45
DOS386 wrote: - the "MZ header format" posted by you (where did you get it from ?) can't be taken too seriously |
|||
|
11 Jul 2008, 12:45 |
|
|
DOS386 11 Jul 2008, 12:46
revolution wrote: you are deliberately ignoring the spec I've not yet seen the spec saying that the MZ header must be at least $40 bytes in size, otherwise the PE header is not guaranteed to be found. > I don't mind being shown to be wrong Same for me. > but you must prove it. I won't simply accept you saying it is wrong with no supporting evidence. How many executables having the "checksum" set to 0 do you want to see ? What sources / compilers / linkers / developers do you accept at all ? |
|||
|
11 Jul 2008, 12:46 |
|
|
revolution 11 Jul 2008, 13:02
DOS386 wrote: How many executables having the "checksum" set to 0 do you want to see ? What sources / compilers / linkers / developers do you accept at all ? |
|||
|
11 Jul 2008, 13:02 |
|
|
DOS386 11 Jul 2008, 13:21
revolution wrote: You are not arguing the proper point. Just because many other apps in the past have broken the checksum (and thus forcing all loaders to ignore it) is not proof that the spec I posted is wrong. The spec is what is supposed to be there 1st, it's a C struct, not a spec, and, 2nd, it shows up what you can store there ... not what is absolutely obligatory ... 3rd, your "spec" doesn't say anything about the valid sizes / minimal size of header (some linkers bloat it even to $0200 bytes instead of just $40), 4th, it doesn't say what to store at $3C if there is no "new" or "next level" executable, thus, FASM's format MZ, creating a $20 bytes header if possible, already does violate your "spec" but storing random garbage at $3C (beyond file size or "negative" possible), and, finally, the "spec" is 24 years old, the original DOS MZ header "spec" got extended by the "new" field when the first NE drafts came up, and nobody bothered to release a precise spec since, and one simply found out that most of the fields are useless garbage, "OEM" is garbage, "checksum" is garbage, all expect "MZ" and stuff at $3C is garbage for PE loaders, and all beyond $20 is garbage for DOS ... as well as nobody ever specified how the MZ file size has to be aligned - linkers align to $0200 bytes, FASM not at all - because nobody ever cared, again  |
|||
|
11 Jul 2008, 13:21 |
|
|
revolution 11 Jul 2008, 13:35
That is more like it, now you are arguing the proper point
Yeah, I posted a C structure, but only for clarity, a full spec would be much larger and obviously contain explanations for the fields. Just because existing OSes choose to ignore certain aspects of the headers is not IMO a good reason to go putting code there. If you have another good reason for doing it then please show that, I am still curious as to why you want to put code there  Specs get updated periodically, some time in the past it was extended to 0x40 bytes to accommodate PE files, so when you make a PE file it would seem a good idea to follow the spec to avoid any possible future nasty bugs that can come back to bite you when you least expect it.
But still you have not shown any evidence to support your two claims: 1) the 10GiB to 1MiB reduction, and 2) that the "spec" I posted is incorrect. |
|||
|
11 Jul 2008, 13:35 |
|
|
Tomasz Grysztar 11 Jul 2008, 13:48
revolution wrote: Just because existing OSes choose to ignore certain aspects of the headers is not IMO a good reason to go putting code there. It's not that he is putting code into headers - on the contrary, he has smaller MZ header, and code after it, and PE offset even later (outside the MZ header boundaries!). If he did put code INSIDE the MZ header, fasm wouldn't touch it. fasm only expands the headers that are too small to fit the PE offset correctly in. |
|||
|
11 Jul 2008, 13:48 |
|
|
revolution 11 Jul 2008, 13:52
I was thinking of the final PE file that DOS386 is suggesting, it is intended to put code into the extended MZ header.
|
|||
|
11 Jul 2008, 13:52 |
|
|
Tomasz Grysztar 11 Jul 2008, 13:55
DOS386 wrote: FASM's format MZ, creating a $20 bytes header if possible, already does violate your "spec" but storing random garbage at $3C (beyond file size or "negative" possible), and, finally, the "spec" is 24 years old, the original DOS MZ header "spec" got extended by the "new" field when the first NE drafts came up, and nobody bothered to release a precise spec since, and one simply found out that most of the fields are useless garbage, "OEM" is garbage, "checksum" is garbage, all expect "MZ" and stuff at $3C is garbage for PE loaders, and all beyond $20 is garbage for DOS ... These fields are not "garbage", since MZ header defines its own size (e_cparhdr field in the structure posted by revolution). If some field doesn't fit into our defined size, it's simply undefined - that's a standard procedure with many kinds of headers (PE also). |
|||
|
11 Jul 2008, 13:55 |
|
|
DOS386 11 Jul 2008, 14:04
revolution wrote: posted a C structure, but only for clarity, a full spec would be much larger and obviously contain explanations for the fields But that's exactly what I'd like to see ... specs stating things like "required" ... "optional" ... "must be set to 0 if not used" ... "after this point unused fields can be dropped" ... Quote: Just because existing OSes choose to ignore certain aspects of the headers is not IMO a good reason to go putting code there. If you have another good reason for doing it then please show that, I am still curious as to why you want to put code there Some people ("tiny-PE"-guru's) mix code + PE header and put it even below $20 ... Quote: specs get updated periodically, some time in the past it was extended to 0x40 bytes to accommodate PE files IIRC wrong ... the $3C field got invented for NE 24 years ago and then just reused for LE/LX and PE ... no updated specs at all 
Quote: still you have not shown any evidence to support your two claims: 1) the 10GiB to 1MiB reduction Look dude, 10 GiB is very much garbage to even read, so don't expect an optimized (<10GiB) Vista today, sorry for letting you wait
> that the "spec" I posted is incorrect. It's obvious that: - It's old - It's obsolete - It's lousy (too many thing left open) - PE header does get found even if the MZ header hogs $20 bytes only Who can say "it's valid to set the MZ header size to $20 and place the position of PE at $3C" or "it's NOT valid to set the MZ header size to $20 and place the position of PE at $3C, random failure can occur then" ? Me NOT, it's not my spec It's up to you to prove that the requirement exists, there is no possibility to prove that something doesn't exist ... I just haven't seen it yet, and since "it works" , it should be safe to assume that such a requirement doesn't exist.
Quote:
Who said that the MZ header must be $40 bytes at least ? |
|||
|
11 Jul 2008, 14:04 |
|
|
Tomasz Grysztar 11 Jul 2008, 14:09
DOS386 wrote: Who can say "it's valid to set the MZ header size to $20 and place the position of PE at $3C" or "it's NOT valid to set the MZ header size to $20 and place the position of PE at $3C, random failure can occur then" ? Since PE position is part of MZ header, the statement that it's OK to set the MZ header size to 20h, and still place the PE offset field at position 3Ch, simply defies logic. You don't even have to use any kind of docs to see how ridiculous such statement is. |
|||
|
11 Jul 2008, 14:09 |
|
|
DOS386 11 Jul 2008, 14:19
Tomasz Grysztar wrote: If some field doesn't fit into our defined size, it's simply undefined It's very doubtful whether the the field at $3C is part of the MZ header ... they just dropped it to some idle area it's irrelevant how big the MZ header and the full MZ EXE are - they could have placed the PE just after the MZ EXE, like DGJPP does with it's COFF, heh NO, they invented the $3C-hack instead allowing the MZ and PE areas to overlap
> since MZ header defines its own size (e_cparhdr field in the structure But wrongly ... M$-linker puts $90,$03 there -> $0490 bytes MZ EXE size, while the PE header sits far below this value ... just doesn't break anything 
Anyway, there are 1'000'000 ways how to "fix" this for me (to get my $20 bytes MZ header) ... if this gets / already got rejected
What about the $0200-bug ? Will this get fixed at least ? > that's a standard procedure with many kinds of headers (PE also) But nobody cares about code in the PE header, PE header in MZ header, header size > file size, ..., ... _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
|
11 Jul 2008, 14:19 |
|
|
DOS386 11 Jul 2008, 14:27
Tomasz Grysztar wrote: simply defies logic. You don't even have to use any kind of docs to see how ridiculous such statement is Considering how "correct" the MZ and PE header and EXE handling always used to be
I'm leaving now (for today, not leaving FASM totally) ... got 33 answers within 3 hours after this topic was dead for 4 months |
|||
|
11 Jul 2008, 14:27 |
|
|
AlexP 12 Jul 2008, 21:30
Quote: I find the dollar ($) character to be very ugly. The 0x format is much clearer IMO. I don't care whether C programmers use it, I also like it and I won't let the I-hate-C brain-washers sway me into using a format that I think is ugly. |
|||
|
12 Jul 2008, 21:30 |
|
| Goto page Previous 1, 2 < Last Thread | Next Thread > |
Forum Rules:
|