This morning while debugging a statistical ichthyo-parser I stumbled upon what looked like a Delphi 2009 compiler bug: the compiler was outputting gibberish ASM opcodes… But after further investigations, it appeared this wasn’t completely gibberish, but that it was (somewhat) correct MSIL bytecode!
What’s more, a quick hexadecimal examination of dcc32.exe yelded that this MSIL codegen looks like it can be forced by using an undocumented command-line compiler switch: -af
The resulting exe won’t run because it’s a mismatch of Win32 headers and MSIL bytecode… What do you think?
Did CodeGear plan supporting unmanaged code in managed executables or managed code in native executables?
Update: here is a screenshot of the switch in action.
Thanks for this. A little experimentation shows that you can patch up the headers with a hex editor easy enough. However, the resulting EXE is weird. It seems to disable garbage collection in .NET. I guess this is for compatibility with the VCL, but I haven’t figured out how they do that yet.
Craig Stuntz: Can you upload the resulting exe somewhere (rapidshare, etc…)?
Torbins, I’m not comfortable with doing that just yet. Remember, the VCL source code manages its memory manually, but the .NET FCL does not. Without GC, on a 2 GB machine, I can exhaust all available memory and crash the system just by moving the mouse around for a few seconds while the application is running. I imagine that this is an issue that will be fixed before the product ships, but perhaps the feature is intended only for 64-bit machines with more memory.
I’m sure there are other issues I haven’t found yet. I wouldn’t want to be responsible for harming someone’s machine.