Renaming DLLs

Everything not related to Prince of Persia should be discussed here.
Post Reply
User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 5743
Joined: April 9th, 2009, 10:58 pm

Renaming DLLs

Post by Norbert »

It's a shame that Windows DLL files don't start with 32 or 64 depending on whether they are 32-bit or 64-bit, e.g. 32SDL2.DLL. That would make it easier to ship a single package with both 32-bit and 64-bit executables. Currently, to have a 'runnable' file in the root (top level) directory, you need a batch file to check if ProgramFiles(x86) is defined, then run the executable in the matching directory.
David
The Prince of Persia
The Prince of Persia
Posts: 2846
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: Random off-topic stuff

Post by David »

Norbert wrote:It's a shame that Windows DLL files don't start with 32 or 64 depending on whether they are 32-bit or 64-bit, e.g. 32SDL2.DLL. That would make it easier to ship a single package with both 32-bit and 64-bit executables. Currently, to have a 'runnable' file in the root (top level) directory, you need a batch file to check if ProgramFiles(x86) is defined, then run the executable in the matching directory.
Well, it is possible to rename it, but then the EXE won't find it...
And the DLL name in the EXE comes from libSDL2.dll.a, which is a binary file.
Not from the *.h text-file that could be easily edited...

There are tools to make *.a from *.dll, but they don't really want to cooperate.
Spoiler: show
There would be a way to create an *.a file from a DLL in one step, but of course it does not really work.

Code: Select all

"C:\Program Files\Dev-Cpp\MinGW64\bin\dlltool.exe" "C:\Program Files\Dev-Cpp\MinGW64\i686-w64-mingw32\bin\SDL2.dll" -l libSDL2.dll.a
The libSDL2.dll.a file gets created, but it will not contain any functions from the DLL!
http://www.mingw.org/wiki/CreateImportLibraries wrote: run 'dlltool -z somedll.def --export-all-symbol somedll.dll' (without 's)

chances are high that you'll get something like 'dlltool: somedll.dll: no symbols'. However, the resulting def-File is a good starting point and probably will need only little additional tweaking.
"Little", as in "the names of all exported procedures are missing and must be added by hand". Duh.
https://sourceforge.net/p/msys2/mailman/msys2-users/?viewmonth=201608&page=1 wrote: It seems `nm` and `dlltool` don't recognize exports in non-mingw libraries. `objdump` recognizes it. I suggest you check with the #mingw-w64 project if this is expected behavior or a known bug, or if the fault lies in our (MSYS2) builds.
It's quite bad when you don't know if something is a bug or a feature.
Here is how to do it anyway:
Spoiler: show
You may need to edit the paths.

Code: Select all

"C:\Program Files\Dev-Cpp\MinGW64\bin\dlltool.exe" "C:\Program Files\Dev-Cpp\MinGW64\i686-w64-mingw32\bin\SDL2.dll" -z SDL2.def
This creates SDL2.def.

Code: Select all

"C:\Program Files\Dev-Cpp\MinGW64\bin\objdump.exe" -x "C:\Program Files\Dev-Cpp\MinGW64\i686-w64-mingw32\bin\SDL2.dll" > SDL2.txt
In SDL2.txt, find "[Ordinal/Name Pointer] Table".

Copy the names from that table into the end of SDL2.def, without the bracketed numbers and the leading whitespace!

Code: Select all

"C:\Program Files\Dev-Cpp\MinGW64\bin\dlltool.exe" "C:\Program Files\Dev-Cpp\MinGW64\i686-w64-mingw32\bin\SDL2.dll" -d SDL2.def -l 32libSDL2.dll.a -f --32 -D 32SDL2.DLL
This creates the 32-bit import library that will cause the compiled EXE to expect a file called 32SDL2.DLL.

Code: Select all

"C:\Program Files\Dev-Cpp\MinGW64\bin\dlltool.exe" "C:\Program Files\Dev-Cpp\MinGW64\i686-w64-mingw32\bin\SDL2.dll" -d SDL2.def -l 64libSDL2.dll.a -f --64 -D 64SDL2.DLL
Same with 64-bit.

(Oh, yeah, that "-f --32" part is one of those things you can't really figure out...)
Problem: I guess SDL2_image.dll will still try to load libpng16-16.dll, for example, without the 32 in the name.
Unless you fully recompile it from scratch... I guess that would not really worth the hassle?

Or you could just, you know, hex-edit the name in the referencing EXE/DLL without changing its length.
Like "libpng16-16.d32" and "libpng16-16.d64" or something.
Um, yeah. This could be the simplest solution. Then you don't need the stuff in the spoilers.
And it "only" took me one hour to find it. Ouch.

What are you trying to do, by the way?
User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 5743
Joined: April 9th, 2009, 10:58 pm

Re: Random off-topic stuff

Post by Norbert »

David wrote:Um, yeah. This could be the simplest solution. Then you don't need the stuff in the spoilers.
And it "only" took me one hour to find it. Ouch.
Sometimes really smart people do unnecessarily complicated things. :)
David wrote:What are you trying to do, by the way?
For my new leapop level editor I wanted to create a single Windows ZIP for both 32-bit and 64-bit.
In the end I decided to just create separate ZIP files. They'll be released soon.
David
The Prince of Persia
The Prince of Persia
Posts: 2846
Joined: December 11th, 2008, 9:48 pm
Location: Hungary

Re: Renaming DLLs

Post by David »

Moved posts to a new topic.
Norbert wrote:For my new leapop level editor I wanted to create a single Windows ZIP for both 32-bit and 64-bit.
I guess a 32-bit executable will run on 64-bit Windows as well.
User avatar
Norbert
The Prince of Persia
The Prince of Persia
Posts: 5743
Joined: April 9th, 2009, 10:58 pm

Re: Renaming DLLs

Post by Norbert »

David wrote:I guess a 32-bit executable will run on 64-bit Windows as well.
In theory, but Moscow Tracer seemed to have problems.
Plus, it's 2017. (current year argument)
Falcury
Calif
Calif
Posts: 565
Joined: June 25th, 2009, 10:01 pm

Re: Renaming DLLs

Post by Falcury »

Norbert wrote:It's a shame that Windows DLL files don't start with 32 or 64 depending on whether they are 32-bit or 64-bit, e.g. 32SDL2.DLL. That would make it easier to ship a single package with both 32-bit and 64-bit executables. Currently, to have a 'runnable' file in the root (top level) directory, you need a batch file to check if ProgramFiles(x86) is defined, then run the executable in the matching directory.
I suppose it should be possible to manually load the DLL at runtime using LoadLibrary()?
Then, the DLL filename can be determined at runtime.
It's probably not the preferred way to do this for SDL2, though... I think you would then have to import all the SDL2 function pointers manually, too :roll:
Post Reply