Index
> Windows > [SOLVED]break of the SSSO principle? my fault |
| Author |
|
|
edfed 06 Feb 2023, 23:10
i tryed to compile again some codes with fasmw 1.73.30.
theses codes were still compiled with success with the same version of fasmw, and the same version of the source. nothing should have been changed and now, when i compile, the binaries are not the same, and the new one doesn't execute... what the f***? is that possible for a window update to modify the fasm compiler behavior? have i a strange virus or so? does a newly installed program modify some stuff somewhere???
Last edited by edfed on 07 Feb 2023, 12:06; edited 1 time in total |
|||||||||||
06 Feb 2023, 23:10 |
|
|
FlierMate11 07 Feb 2023, 07:35
Nice polygon.exe.bak that you have, nice graphics, but they are not the same size.
Original is 32,768 bytes (0x8000), but polygon.exe is 33,280 (0x8200), the file alignment is correct though. I took a look via hexdump, both headers are not the same. I will post again after I inspect with CFF Explorer. |
|||
|
07 Feb 2023, 07:35 |
|
|
FlierMate11 07 Feb 2023, 07:44
The section headers are not the same, the VirtualSize and RawSize between code sections, for example, are different in size. I don't know how come they become like this if compiled from the same source with the same assembler.
Looks like your newly compiled polygon.exe has extra 0x200 bytes of code section. That explains why polygon.exe is 512 bytes longer than original working executable.
|
|||||||||||||||||||
|
07 Feb 2023, 07:44 |
|
||||||||||||||||||
|
FlierMate11 07 Feb 2023, 07:59
It does look like the disassembled code is not the same, too. I will post again after insepcting with Ghidra.
Sorry for multiple posts. I am not good in debugging, so I will just show the few lines in the beginning of the EXE: Disassembly: Code: original working exe: 00401000 6a 00 PUSH 0x0 00401002 ff 15 a4 CALL dword ptr [->KERNEL32.DLL::GetModuleHandleA] = 000020ee 20 40 00 00401008 a3 33 30 MOV [DAT_00403033],EAX 40 00 0040100d 6a 11 PUSH 0x11 0040100f 50 PUSH EAX 00401010 ff 15 ac CALL dword ptr [->USER32.DLL::LoadIconA] = 00002290 21 40 00 00401016 a3 37 30 MOV [DAT_00403037],EAX 40 00 newly compiled non-working exe: 00401000 6a 00 PUSH 0x0 00401002 ff 15 a4 CALL dword ptr [->KERNEL32.DLL::GetModuleHandleA] = 000020ee 20 40 00 00401008 a3 33 30 MOV [DAT_00403033],EAX 40 00 0040100d 50 PUSH EAX 0040100e ff 15 ac CALL dword ptr [->USER32.DLL::LoadIconA] = 00002290 21 40 00 00401014 6a 11 PUSH 0x11 00401016 ff 15 ac CALL dword ptr [->USER32.DLL::LoadIconA] = 00002290 21 40 00 0040101c a3 37 30 MOV [DAT_00403037],EAX 40 00 As you can see, the non-working LoadIconA only take one parameter at a time: Code: HICON LoadIconA( [in, optional] HINSTANCE hInstance, [in] LPCSTR lpIconName ); It is supposed to be two parameters, which is correct in the first polygon.exe. Hope this give some help already! |
|||
|
07 Feb 2023, 07:59 |
|
|
edfed 07 Feb 2023, 08:57
hooo, i get it.
that's my fault. i tryed this in proc32.inc from fasm MACRO includes. Code: macro stdcall proc,[arg] ; directly call STDCALL procedure { common if ~ arg eq reverse pushd arg common end if call proc } macro invoke proc,[arg] ; indirectly call STDCALL procedure { stdcall [proc],arg } what is incredible is that the fasmw compiled with this version of macro works... and can compile itsleft... WTF again. but at least i can reuse my code. thank you. i am not so familiar with MZ format. |
|||
|
07 Feb 2023, 08:57 |
|
|
ProMiNick 07 Feb 2023, 09:16
edfed wrote:
it is equivalent to Code: macro invoke proc,[arg] ; indirectly call STDCALL procedure { forward stdcall [proc],arg }; so for every instance of arg made separate one call but thou need this I guess: Code: macro invoke proc,[arg] ; indirectly call STDCALL procedure { common stdcall [proc],arg } _________________ I don`t like to refer by "you" to one person. My soul requires acronim "thou" instead. |
|||
|
07 Feb 2023, 09:16 |
|
|
revolution 07 Feb 2023, 09:21
edfed wrote: ... fasmw compiled with this version of macro works... and can compile itsleft... |
|||
|
07 Feb 2023, 09:21 |
|
|
edfed 07 Feb 2023, 11:02
ok, then it's completelly solved... as always, the bug comes from the guy on the chair
|
|||
|
07 Feb 2023, 11:02 |
|
|
AsmGuru62 07 Feb 2023, 16:50
It is a rare thing to meet a compiler bug, the real one.
I saw a case of this only once in ... well, I code since 1984. In famous VC++ 6.0 if you use "?:" expressions inside a for( ... <-- here --> ...) loop -- the Debug version is OK, but Release will crash -- optimizer fails to do it properly. |
|||
|
07 Feb 2023, 16:50 |
|
< Last Thread | Next Thread > |
Forum Rules:
|