| Revision | a2fb577d02e3ad4da369c64b0dd5280f9d88909d (tree) |
|---|---|
| Zeit | 2016-10-27 06:21:11 |
| Autor | OCTAGRAM <bo_ <gen@octa...> |
| Commiter | OCTAGRAM <bo_ |
Described found differences
| @@ -0,0 +1,43 @@ | ||
| 1 | +SOM 2.1 for Windows is compiled with Microsoft C, and SOM 3.0 for Windows is compiled with VisualAge for C++. | |
| 2 | + | |
| 3 | +Both have samples, and samples contain compiler switches. SOM 2.1 contain compiler switches for both Microsoft C and VisualAge for C++, SOM 3.0 only contains VisualAge for C++ switches. | |
| 4 | + | |
| 5 | +VisualAge for C++ allocates as little space for enum as possible (controlled by /Su switch), while Microsoft C allocates int (4 bytes). This is notable when opening emitdef.dll (or any other emitter) in IDA. Where SOM 2.1 has "dword ptr [eax+4]", SOM 3.0 has "byte ptr [eax+4]". All Emitter Framework enums are affected! They are hacked to be C enums as opposed to normal SOM enums. | |
| 6 | + | |
| 7 | +With regards to the switches used to build samples (found in samples\VACMAKE.HD and samples\MSCMAKE.HD): | |
| 8 | + | |
| 9 | +SOM 3.0: | |
| 10 | +CFLAGSCOMMON = /Ti /O- /Os- /W1 /H128 /Q+ /c /Gd+ /Gm+ | |
| 11 | + | |
| 12 | +SOM 2.1: | |
| 13 | +CFLAGSCOMMON = /Ti /O- /Os- /W1 /H128 /Gs+ /Sp1 /Q+ /c /Gd+ /Gm+ | |
| 14 | + | |
| 15 | +You should see the difference here. | |
| 16 | + | |
| 17 | +/Gs+ Remove stack probes | |
| 18 | +/Sp1 Packing of data items | |
| 19 | + | |
| 20 | +SOM 2.1 (MSVC): | |
| 21 | +CFLAGSCOMMON = /MT /G4 /Gs /Zp /Od /H128 /Zi /c /D_WIN32 | |
| 22 | + | |
| 23 | +/MT | |
| 24 | +/G4 G4 386 instructions, optimize for 486 | |
| 25 | +/Gs Controls stack probes. | |
| 26 | +/Zp Packs structure members. | |
| 27 | +/Od Disables optimization. | |
| 28 | +/H128 Deprecated. Restricts the length of external (public) names. | |
| 29 | +/Zi Generates complete debugging information. | |
| 30 | +/c | |
| 31 | +/D_WIN32 | |
| 32 | + | |
| 33 | +So it looks like SOM 2.1 packs structures, there are switches for both Microsoft C and VAC; and SOM 3.0 does not. At the moment no any known record can exhibit the difference, but this should be further investigated, and Delphi records should probably be made packed ones. | |
| 34 | + | |
| 35 | +Also note the difference in headers: | |
| 36 | +2.1: | |
| 37 | +typedef enum completion_status {YES, NO, MAYBE} completion_status; | |
| 38 | +3.0: | |
| 39 | +typedef enum completion_status {YES, NO, MAYBE, | |
| 40 | + completion_status_MAX = 2147483647 /* ensure mapped as 4 bytes */ | |
| 41 | +} completion_status; | |
| 42 | + | |
| 43 | +As soon as MSVC compiler is used for SOM 2.1 samples, the enum is 4 bytes and consistent with SOM DLL ABI, but VAC compiler is supposedly broken. /Sp1 should make the structure Environment packed, change size and offsets in Environment. That makes it harder to verify assumptions about ABI. The first option is IDA, it unveils how do original DLLs work with data. The second option is to construct custom tk_struct TypeCodes and check tcSize on them. | |
| \ No newline at end of file |
Fork
Known differences between SOM 2.1 and SOM 3.0.md