#406 HARDSID: fix LoadLibrary() for using TCHARs

[Carlo Bramini]

My port to Visual Studio signals a tiny defect into vice/src/arch/shared/hwsiddrv/hs-win32-dll.c
The function LoadLibrary() accepts TCHAR and not char, so the name of the DLL to load must use the TEXT() macro.
Attached patch fixes this easy issue.

[gpz]

good catch - however, i think this needs a different fix:

a) in ./arch/shared/hwsiddrv/hs-win32-dll.c:117 change LoadLibrary to vice_dynlib_open (and probably somewhere in the same file replace FreeLibrary by vice_dynlib_close)
b) in ./arch/shared/dynlib-win32.c:99 add the TEXT() macro

assuming that macro accepts a pointer to chars that is, if not, we have a problem

[gpz]

https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-text

This leaves more questions than it answers - the macro returns (void) ? how is that supposed to be passed into LoadLibrary?

comitted a fix in r45860 - someone needs to test if this works

[gpz]

Btw:

The function LoadLibrary() accepts TCHAR and not char, so the name of the DLL to load must use the TEXT() macro.

That is not entirely true. depending on wether UNICODE is defined globally or not, LoadLibrary will be defined as LoadLibraryA or LoadLibraryW - and the only latter takes TCHAR.

That said, since our builds dont do this, it is probably not a good idea to do it in your builds either. I dont think anyone tested if it even works right :)

[gpz]

PS: you say you use visual studio - it would be interesting to see how much you had to change/patch to do this, and what your setup (project files etc) look like. I tried to do it a while ago in the "free" edition, with little success (i tried using the --enable-cmake stuff in the buildsystem). If you like, make an extra ticket for this, please

[Querino]

i always had the impression, it doesn't make any differenc if we use TCHAR or char, as long as we do an ANSI compile...

ANSI compile: TCHAR -> char
Unicode compile: TCHAR -> WCHAR

[gpz]

Yes, that is correct. I think Visual Studio complains either way though(?)

[Carlo Bramini]

I have seen the changes, but they are wrong.
You cannot use TEXT() macro on variables, you must it only on compile-time constant literals.
Doing this at runtime requires the use of MultiByteToWideChar() function.
The code into arch/shared/dynlib-win32.c is pretty raw but it can be made unicode compliant with very little effort (4 lines of code)... I can do it if you want, so that code would be technically ready for it.
However, into arch/shared/hwsiddrv/hs-win32-dll.c, there is an #ifdef WINDOWS_COMPILE ... #endif, so at the time of writing this is expected to work only on Windows.
Is it worth to use vice_dynlib_open() instead of LoadLibrary()?

Note: I discovered that thing thanks to my port to Windows CE.
On CE, you have only unicode functions and only LoadLibraryW() exists.
So, unicode is always activated by design.
It was just a challenge to make VICE working on Windows CE and that was easy to fix.
However, at the end I decided disable HAVE_HARDSID because the hardware resources are quite limited. Anyways, the call to that LoadLibrary() was correct to be fixed, at least in my opinion.

[Carlo Bramini]

I just did a quick patch to dynlib-win32.c, now it is much more "universal".
I hope that you will find it useful.

[gpz]

I agree that the windows specific code doesn't need the vice_dynlib stuff, its not portable anyway.

Thanks for that patch, applied in r45864