I hope someone can help me out with the following:
Some years ago I Glk-fied my XVAN console interpreter to a Glk version. I downloaded the WindowsGlk-148.zip by David Kinder and made windows and linux Glk versions of my interpreter. I used the Code::Blocks IDE for the build.
Now I want to release the source code, but with a makefile to build the executable, so people don’t have to install Code::Blocks to build it.
On my windows system I have mingw32-make, which I also use to build the console version of the interpreter. I changed the makefile from the console version to link against the Glk libraries and then found that the Glk.dll and Glk.lib cannot be used with mingw32-make (something with an unsupported format).
So, next I dumped the Glk.dll to find the names of the 360 functions that are in it. I made a .DEF file with these names and used mingw32’s dlltools to create a libGlk.a lib that can be handled by mingw32-make.
With this new library the executable builds and there were no undefined references.
But, when I start the application it throws an “Application was unable to start correctly (0xc000007b) error. Solutions I found vary from restarting windows to reinstalling the .net framework.
But I suspect there’s something wrong with the application. The build I made with Code::Blocks runs fine, only this mingw build does not.
I know Glk also requires ScaleGfx.dll. I have it in the application directory together with Glk.dll and the application is not complaining about any of them.
I’v been working on this for some time now and I think I need help to get this solved. Any ideas?
Just a wild stab in the dark, but make sure the library and program are both compiled for the same architecture (32 or 64 bit).
If you’re more familiar with a *nix environment you may want to use a cygwin or msys2 console, where you’ll have useful utilities like file to get details on whether a DLL was compiled for 32 or 64 bit. I’m sure there’s probably a more Windows-friendly way to do this, but I don’t know what it is. WSL is another option here, but then you need to cross-compile which can be more tricky.
Also make sure you decide whether you want to link it statically or dynamically, and whether you’re actually doing whichever one you want to be doing.
For stuff like this I usually like to get it to build just using gcc directly before messing with a makefile.
There is a def file included in the Windows Glk source distribution, but as you’ve made your own now …
0xc000007b usually means that Windows couldn’t find a needed DLL. I’m guessing, but the first thing I would guess is that this isn’t actually related to Windows Glk - it may be that the executable is looking for the MinGW run-time DLL. Back in the past MinGW binaries didn’t have any (or at least many) DLL dependencies, but I think that that has changed. I would test this by first compiling a simple “hello world” C program with MinGW, with no Glk use, and see if you can get that to run. If that gives the same error, that is likely the problem.
Thank you. I took the makefile from the console version of the interpreter and changed that for Glk. The console version of the interpreter (without the Glk code) compiles and runs ok with mingw32.
I’ll download depends.exe when I get home. I believe depends also can tell whether a dll is for 64 or 32 bits.
Ok, I got depends.exe. It gives lots of messages, also for apps that work fine. It even reports errors on its own dll
Here are some findings:
Note:
interpreter.exe is the non-Glk interpreter
Glk-interpreter.exe is the Glk version.
My windows system is 64-bits, system dlls like kernel32, ntdll, kernelbase are 64-bits
Glk.dll is 32 bits
When building with Code::Blocks, both interpreter.exe and Glk-interpreter.exe are 32-bits applications.
The 32-bits interpreter.exe and Glk-interpreter.exe from Code::Blocks both run on my 64-bits windows. Depends.exe does report that modules with different CPU types were found, though.
When building with mingw32-make, both interpreter.exe and Glk-interpreter.exe are 64-bits (don’t let the name mingw32 confuse you, it creates 64-bits applications).
The 64-bits interpreter.exe from mingw does run on my system. Depends.exe does not report different CPU types.
The 64-bits Glk-interpreter.exe from mingw does not run on my system. Depends.exe reports different CPU types. Among others, Glk.dll is 32 bits.
So, can the issue be caused by the fact that mingw creates a 64-bits application while the Glk.dll is 32 bits?
I cannot find a way to make my mingw32-make create a 32-bits application. Before installing a whole new (old) mingw that creates 32 bits I’d like to assess whether this might solve the problem.
“depends.exe” sometimes gets a little confused about things, but the rule is that 64-bit and 32-bit processes are different things. A 32-bit DLL cannot be used with a 64-bit executable, and vice versa. So yes, in answer to your question, this is why your executable doesn’t work.
Windows Glk’s Glk.dll is 32-bit. A 64-bit version could be built, using a recent version of Microsoft Visual Studio, but there wouldn’t really be much point - right now there’s no interpreter that needs a 64-bit address space. The only practical solution is to build a 32-bit executable.
Question: where did you get MinGW from? My understanding is that http://www.mingw.org/ is a 32-bit toolchain that only produces 32-bit executables. http://mingw-w64.org/ is a 64-bit toolchain that can produce 32-bit and 64-bit executables. MinGW always seemed a bit of a mess to me, with multiple versions floating round.
It would also be helpful to know the command line that make is running to actually call GCC. If I recall correctly, in MinGW-w64 there are separate versions of GCC for producing 32-bit (x86) and 64-bit (x64) output.
The good news is that it works! I can now make a build using the makefile.
It was the 64 bits issue indeed. I have a mingw-w64 that came with the installation of the Qt framework. This produces 64-bit executables.
I saw that Code::Blocks uses the MinGW version, which is 32-bits. So I downloaded it from mingw.org and now I got a 32-bits executable that worked. Only, it did not recognize the new library I made, so I used the one that came with Glk again.
This is what I found about MinGW and MinGW-w64:
MinGW is a GCC-port for Windows. … MinGW-w64 is a improved version which supports both 32bit and 64bit, and some more of the WinAPI (still not all, because thats much work, but more than MinGW). MinGW-w64 only provides their source code, but no binaries to “just use” the compiler.
I’m not sure if MinGW-64 can create 32-bits executables. I searched the net but could not find anything about it, only that it runs on 32 and 64 bit.
I did see 2 nearly identical folders that only differ in name by 32/64. Both have a gcc.exe, but I ended up with a 64-bits executable with each of them.
I will make the release notes reflect that the build must be 32 bits.
AFAIK you can use the -m32 gcc flag to generate 32 bit executables with MinGW-64, but you need to have the appropriate packages installed. I only have a minimal installation and get lots of link errors when I try it.
