Yes, that's about all the difference there is 😉

Btw, another nice side effect of changing the glide.cpp is that if you have libglide2x in the same folder as the dosbox binary, it will just work when you doubleclick dosbox in Finder 😉
(If you don't have libglide in /usr/local/lib that is)

Dominus wrote on 2021-03-13, 11:47:

Yes, that's about all the difference there is 😉

Btw, another nice side effect of changing the glide.cpp is that if you have libglide2x in the same folder as the dosbox binary, it will just work when you doubleclick dosbox in Finder 😉
(If you don't have libglide in /usr/local/lib that is)

I think you just answered by edited question above, thanks. 😀

I have a quick question .. the list of patches to my SVN fork is growing, and some of these patches required substantial modifications to work on the Mac. It will be time consuming to have to manually re-apply them when I want to update the SVN source.

What is currently the easiest way to make diff patches on the Mac? Will I have to resort to command line tools? Currently I am using Github desktop to make and upload changes to the source.

I made sure that each patch was pushed to origin with an individual commit.

@almeath - This goes back to the "launcher" inside your app bundle.

Instead of the launcher executable, create a script named something like "Wrapper" with these contents:

1#!/bin/bash
2
3cd "$(dirname "$0")"
4cd ../Resources
5./dosbox/dosbox -conf dosbox_settings.conf -conf dosbox_launch.conf

After you create it, use chmod +x to make it executable, and move it into your MacOS folder.

Then rename your app bundle "Wrapper" and change the executable name in the info.plist to "Wrapper". Now, when you launch the app bundle, you will get the same result that you got with your original app.

The trouble with this is that the script needs to have the same name as the bundle and the same name has to be in the info.plist, and users can't be counted on not to change the name of the bundle. But maybe it's an idea worth playing with?

almeath wrote on 2021-03-13, 14:19:

I have a quick question .. the list of patches to my SVN fork is growing, and some of these patches required substantial modifications to work on the Mac. It will be time consuming to have to manually re-apply them when I want to update the SVN source.

What is currently the easiest way to make diff patches on the Mac? Will I have to resort to command line tools? Currently I am using Github desktop to make and upload changes to the source.

I made sure that each patch was pushed to origin with an individual commit.

So you got each patch self contained if I understood your last sentence correctly?
Make sure you keep it that way and just script applying each patch.
There is a SVN command to clean it but you might as well script it to delete your SVN copy and check it out fresh.
(There it comes handy to keep one copy for playing around with tests and one that is only used to build your patched version).

There is another way involving to have to clone Dosbox SVN to git and then do that for each new commit and then rebase your changes. I'm not sure that is the right solution for you (definitely not for me).

emendelson wrote on 2021-03-13, 14:46:

The trouble with this is that the script needs to have the same name as the bundle and the same name has to be in the info.plist, and users can't be counted on not to change the name of the bundle. But maybe it's an idea worth playing with?

Thanks for that suggestion. That was in fact the same reason I decided to stay with the launcher, as I quite often want to change my info.plist and bundle names. I will definitely look into this though.

The approach I take is to have a pre-built wrapper, and then duplicate it to create new game wrappers, which necessitates changing the internals of the wrapper, including the info.plist and bundle name. So the suggested approach probably would not work for my purposes, but if there was to be a script created to automatically package up a game, then that would be different. 😀

Dominus wrote on 2021-03-13, 14:56:

So you got each patch self contained if I understood your last sentence correctly? Make sure you keep it that way and just scrip […]
Show full quote

So you got each patch self contained if I understood your last sentence correctly?
Make sure you keep it that way and just script applying each patch.
There is a SVN command to clean it but you might as well script it to delete your SVN copy and check it out fresh.
(There it comes handy to keep one copy for playing around with tests and one that is only used to build your patched version).

There is another way involving to have to clone Dosbox SVN to git and then do that for each new commit and then rebase your changes. I'm not sure that is the right solution for you (definitely not for me).

Yes, I believe they are all self contained. The former approach does sound more appealing. I will look into this, thanks.

Forgot to mention, the reason to keep them self contained is that you don't have to figure out which patched functionality is the culprit if it were one big patch that fails to apply.

We need the recap guy from the Ant-Man movie to recap this thread 😉

Dominus wrote on 2021-03-13, 15:16:

Forgot to mention, the reason to keep them self contained is that you don't have to figure out which patched functionality is the culprit if it were one big patch that fails to apply.

We need the recap guy from the Ant-Man movie to recap this thread 😉

Ha ha, true. Yeah, I made a mistake with one large patch for the 8GB hard drive size, and had to adjust it, but the rest were done in one commit each.

I am actually just not sure how to go about scripting this stuff, but will research it. It is too bad Github desktop does not provide a feature to help convert commits into diff files.

It's easy to create a diff file from the mac Terminal. See this page:

https://stackoverflow.com/questions/20397345/ … ile-on-mac-os-x

another fix for the libglide2x.dylib loading:

1#elif defined(MACOSX)
2	hdll = dlopen("@executable_path/libglide2x.dylib", RTLD_NOW);
3	if (!hdll)
4		hdll = dlopen("libglide2x.dylib", RTLD_NOW);
5#else

with this it will first try to open the dylib next to the dosbox binary and if that is not working it will use the old way.

1checking for X... libraries , headers

You're good, the configure scripts detected X and no additional defines were required for headers and libs.
The GL definition is not part of the X. On Linux, that's from MESA, I believed. Perhaps you could try getting mesa from the homebrew, too. If the homebrew provides separate packages for runtimes and devel, then you could try with only the devel.

You can also try searching for a simple GL/GLX colored triangle sample C code and see if it will compile with your existing XQuartz/OpenGL setup.

> It is too bad Github desktop does not provide a feature to help convert commits into diff files.

When viewing a commit:

Slap a ".diff" on the end of the URL and ...

.. it'll give you the plain-text diff (handy for scripting too).

Also works for entire PRs (of multiple commits) to produce multi-file diffs.

Wow, that is a neat trick .. exactly what I needed, thanks! Quick and easy. 😀

Dominus wrote on 2021-03-13, 17:44:

another fix for the libglide2x.dylib loading: […]
Show full quote

another fix for the libglide2x.dylib loading:

Copy code to clipboard

1#elif defined(MACOSX)
2	hdll = dlopen("@executable_path/libglide2x.dylib", RTLD_NOW);
3	if (!hdll)
4		hdll = dlopen("libglide2x.dylib", RTLD_NOW);
5#else

with this it will first try to open the dylib next to the dosbox binary and if that is not working it will use the old way.

Is it possible to have two fall backs? i.e. first it looks in the current directory, then perhaps I could have it look relative to the executable under Resources/lib/glide (to work within my preferred package structure), and lastly looking for the system level install? I could then combine that with your earlier install_name_tool suggestion to make sure that only one copy of SDL 1.2.0 is needed in the package. I just think that within a package structure it is tidier to have the glide dylibs in the lib directory with all the others. If that cannot be made to work I would stick with my current approach of having the dylib fallback specified in my script.

kjliew wrote on 2021-03-13, 22:24:

You're good, the configure scripts detected X and no additional defines were required for headers and libs. The GL definition is […]
Show full quote

Copy code to clipboard

1checking for X... libraries , headers

You're good, the configure scripts detected X and no additional defines were required for headers and libs.
The GL definition is not part of the X. On Linux, that's from MESA, I believed. Perhaps you could try getting mesa from the homebrew, too. If the homebrew provides separate packages for runtimes and devel, then you could try with only the devel.

You can also try searching for a simple GL/GLX colored triangle sample C code and see if it will compile with your existing XQuartz/OpenGL setup.

Thanks for those suggestions .. I will report back if I can make further progress with them. Just a quick question.. what outputs am I expecting from the build? I.e. I see the glide2x and 3x .la files, but I am not sure how those would be made to work with DOSBox given that it expects .lo and .dylib files for Linux and Mac respectively.

Almost there with qemu-xtra, having installed Mesa with Homebrew*, and separately editing the window.cpp header to provide the right X11 location ( /opt/X11/include/X11 ).

*I had to copy in a glu.h file from my X11 install (don't know if that's advisable or not?)

It is now only failing due to this error:

1ld: symbol(s) not found for architecture x86_64
2ld: symbol(s) not found for architecture x86_64
3clang: error: linker command failed with exit code 1 (use -v to see invocation)
4clang: error: linker command failed with exit code 1 (use -v to see invocation)
5make[2]: *** [libglide3x.la] Error 1
6make[2]: *** Waiting for unfinished jobs....
7make[2]: *** [libglide2x.la] Error 1
8make[1]: *** [all-recursive] Error 1
9make: *** [all] Error 2

almeath wrote on 2021-03-14, 04:28:

Just a quick question.. what outputs am I expecting from the build? I.e. I see the glide2x and 3x .la files, but I am not sure how those would be made to work with DOSBox given that it expects .lo and .dylib files for Linux and Mac respectively.

I am not really well-versed in the art of configure scripts. They are the same from the very old upstream OpenGlide CVS with minor additions to produce another Glide3x library. The format of objects and libraries should be resolved by itself by native compiling, otherwise there are serious issues with the build environment.

almeath wrote on 2021-03-14, 04:19:

Dominus wrote on 2021-03-13, 17:44:

another fix for the libglide2x.dylib loading: […]
Show full quote

another fix for the libglide2x.dylib loading:

Copy code to clipboard

1#elif defined(MACOSX)
2	hdll = dlopen("@executable_path/libglide2x.dylib", RTLD_NOW);
3	if (!hdll)
4		hdll = dlopen("libglide2x.dylib", RTLD_NOW);
5#else

with this it will first try to open the dylib next to the dosbox binary and if that is not working it will use the old way.

Is it possible to have two fall backs? i.e. first it looks in the current directory, then perhaps I could have it look relative to the executable under Resources/lib/glide (to work within my preferred package structure), and lastly looking for the system level install? I could then combine that with your earlier install_name_tool suggestion to make sure that only one copy of SDL 1.2.0 is needed in the package. I just think that within a package structure it is tidier to have the glide dylibs in the lib directory with all the others. If that cannot be made to work I would stick with my current approach of having the dylib fallback specified in my script.

yes, that is actually not a problem, now that I figured it out 😀

1#elif defined(MACOSX)
2	hdll = dlopen("@executable_path/libglide2x.dylib", RTLD_NOW);
3	if (!hdll)
4		hdll = dlopen("@executable_path/../lib/glide/libglide2x.dylib", RTLD_NOW);
5	if (!hdll)
6		hdll = dlopen("libglide2x.dylib", RTLD_NOW);
7#else

and the loader path for the install_name_tool should be

1@loader_path/../libSDL-1.2.0.dylib

(that is if you still have the dosbox binary in Resources/dosbox and libglide in Resources/lib/glide)

HOWEVER I have not found a way to have the bundle find the glide2x.ovl inside itself. The @loader/executable way does not work for the way this is being used. It works fine however with the glide2x.ovl being in the game folder.

Dominus wrote on 2021-03-14, 19:50:

HOWEVER I have not found a way to have the bundle find the glide2x.ovl inside itself. The @loader/executable way does not work for the way this is being used. It works fine however with the glide2x.ovl being in the game folder.

Thanks Dominus, I have updated my source on Github to reflect this patch. I tested it out and it now works with only the one copy of SDL 1.2.0 dylib inside the wrapper. 😀

I was not aware that it would have been possible to point the Glide dylib to the ovl file. I have left a copy inside the wrapper in the C drive so that it will be available for individual game installations.