Brandy on Windows 8.1

[jgharston]

Has anybody tested Brandy on Windows 8.1? I've been temporarily using my neighbour's Win8.1 laptop for testing and GitHubing.

Brandy Win/DJPP gives 'Cannot run on this version of Windows' - fairly expected as it's a DOS target. Brandy Win/MinGW runs fine. Brandy WinSDL gives 'SDL.dll not present' (I believe, as it's in Chinese). Trying to install SDL.dll with regsrv32 gives 'Module SDL.dll failed to load ... The module could not be found'

Works fine on her Win8.0 desktop.

[soruk42]

My wife's laptop is Win8.1 - not had any problems with the binaries I've built on my Win7(x86)/Cygwin build environment. I statically link the SDL-1.2 library.

[soruk42]

Likewise, I can just drop the brandy.exe binary on my (work!) Win10 laptop, and it works fine.

[jgharston]

I'm getting other problems on this Win8.1 laptop, so I think it may be this machine.

[jgharston]

I've solved the problem, you need a 64-bit build of sdl.dll. It's fiddly as almost all web searches for SDL 1.2 give you the 32-bit DLL, it was by accident that I found a 64-bit build. I'm going to check the distribution conditions and put sdlx32.dll and sdlx64.dll in the binaries folder.

[soruk42]

Perhaps in your build you can statically link to SDL, that way the target machine has no dependency on external third-party libraries. For instance, I'm using the MinGW libSDL.a as shipped by Cygwin. (My build does not rely on Cygwin at runtime, I just use it as a build environment that fits what I'm comfortable with).

[jgharston]

On 14-10-2019 09:27, Michael McConnell wrote:

Perhaps in your build you can statically link to SDL, that way the target machine has no dependency on external third-party libraries. For instance, I'm using the MinGW libSDL.a as shipped by Cygwin. (My build does not rely on Cygwin at runtime, I just use it as a build environment that fits what I'm comfortable with).

But doesn't that mean having to have a different build for each operating system?

Instead of a Windows SDL build that says "hello, tell me where the SDL module is", so will run on any Windows using whatever SDL module is there on that Windows, instead you have a Windows SDL build that calls Windows SDL code embedded inside it, which will be whatever SDL code was embedded when it was embedded, and if it was the 32-bit SDL code, it won't run on 64-bit Windows, and if it was the 64-bit SDL code, it won't run on 32-bit Windows.

I thought the whole point of DLLs was just as with Modules in RISC OS in that the application doesn't need to know or care what target the dll/module has targetted, it just calls it, and it's the responsibility of whoever has set up the Windows the application is running on to provide the dll that interfaces with that version of Windows.

-- J.G.Harston - jgh@mdfs.net - mdfs.net/jgh

[soruk42]

I build my binaries on Win7 32-bit, they run just fine on WinXP 32-bit, Win8.1 64-bit and Win10 64-bit. As things currently stand, Win7 64-bit and later can run 32-bit binaries quite happily.

On October 14, 2019 9:04:45 PM GMT+01:00, jgharston notifications@github.com wrote:

On 14-10-2019 09:27, Michael McConnell wrote:

Perhaps in your build you can statically link to SDL, that way the target machine has no dependency on external third-party libraries. For instance, I'm using the MinGW libSDL.a as shipped by Cygwin. (My build does not rely on Cygwin at runtime, I just use it as a build environment that fits what I'm comfortable with).

But doesn't that mean having to have a different build for each operating system?

Instead of a Windows SDL build that says "hello, tell me where the SDL module is", so will run on any Windows using whatever SDL module is there on that Windows, instead you have a Windows SDL build that calls Windows SDL code embedded inside it, which will be whatever SDL code was embedded when it was embedded, and if it was the 32-bit SDL code, it won't run on 64-bit Windows, and if it was the 64-bit SDL code, it won't run on 32-bit Windows.

I thought the whole point of DLLs was just as with Modules in RISC OS in that the application doesn't need to know or care what target the dll/module has targetted, it just calls it, and it's the responsibility of whoever has set up the Windows the application is running on to provide the dll that interfaces with that version of Windows.

-- J.G.Harston - jgh@mdfs.net - mdfs.net/jgh

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/stardot/MatrixBrandy/issues/67#issuecomment-541891375

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.