Great idea!

Sorry. I posted too soon. I've removed the file until I get it to work correctly again!

It's fixed now, I think. I always forget to test these things with paths that include spaces. The job of getting a quoted path (with spaces) into an echo command in a shell script is always a nightmare. But I think this works now. Same download as before. Apologies to anyone who downloaded earlier.

Suggestion:

In the contained cdrive.conf, replace

1Mount -t floppy C: "/Users/yourname/Desktop/Two Words/DOSBoxApp.app/Contents/Resources/Files/CDrive"
2Mount -t floppy D: /Users/yourname/Desktop/

by

1Mount -t floppy C: "~/Desktop/Two Words/DOSBoxApp.app/Contents/Resources/Files/CDrive"
2Mount -t floppy D: ~/Desktop/

~ stands for the User's folder.

I second the answer of Dominus, this is great!

Excellent suggestion! By the way, the contained drive.conf gets rewritten every time the AppleScript gets launched, so what you're quoting is the text that happened to be in the app when I posted it. Now that I've moved it somewhere else it reads:

1Mount -t floppy C: "/Users/edward/WPDOS Files/DOSBoxApp.app/Contents/Resources/Files/CDrive"

I think I see a way to parse the path reliably to remove the /Users/yourname part and replace it with ~. I'll work on that.

About using ~/Desktop: is the Desktop always named Desktop, even in non-English systems? As it stands, I have the AppleScript write out the POSIX path to the Desktop.

Yes, it's always Desktop, same as it is always Documents, only the "locale" something changes so it appears differently in the nonEnglish system.

OK - thanks for clarifying that. I'll change the Mount D: line to use ~/Desktop.

Meanwhile, just to explain: I construct the .conf file by starting with a file that contains a lot of default settings; this file doesn't change; then the AppleScript creates a temporary file with the "mount C:" line, pointing to the path to a folder deep inside the application itself; then I combine the default settings and the temporary file to create the .conf file that gets used when you launch the application.

To be honest, I find Boxer to be a much better solution in principle for this. As oppose to having many installations of dosbox, each in their own wrapper, we have one installation and each game in their own "boxes" that is launched with the app, and can be clicked on as if they each were their own app. Unfortunately, development has been ceased. The man really needs help.

https://github.com/alunbestor/Boxer/issues/56

I'm sure Boxer is a far better solution than this one. Boxer is the product of years of work. I threw together this AppleScript application in a few minutes, mostly by removing things that I had already written for something else. Absolutely, Boxer is far better. Of course, with my AppleScript, you can make multiple copies, change the name of each, and use them to run as many programs as you like, but that's not the same as the efficient and elegant method used by Boxer.

On the other hand this is really nice applescript work! I've used some basic commands to tell the Terminal.app to run a man/info page for an app, but I was always curious to learn more. Can you recommend a good resource?

If you look at the Dosbox wiki you can see another nice way to use AppleScript with many configs for Dosbox. There are good books about it and some good forums that are always a nice help.
The upside of using the original Dosbox is that the topic won't get closed, as it will happen with boxer topics 😉

Thanks will do. I saw a few "guides" on the internet, as well as apple's documentation, but nocomplete online resources like Mendel Cooper's guide for advanced bash scripting.

Well the trick is to know the difference between a dosbox issue and a boxer one. 😀 (Bering in mind that Alun ripped out all the SDL code and replaced it with native solutions) Alun is pretty approachable and has always done his own support.

I wonder if this could be a starting point for Mac versions of my installers.

Darklord42 wrote:

Thanks will do.

Well the trick is to know the difference between a dosbox issue and a boxer one. 😀 (Bering in mind that Alun ripped out all the SDL code and replaced it with native solutions) Alun is pretty approachable and has always done his own support.

Boxer does not use stock DOSBox, so this is not the place to ask about any problems with Boxer.

No one is recommending otherwise. But with all things with an upstream project, there can be times when you should go to the upstream project. That's all I'm saying

Of course but only when the problem occurs with the upstream project as well.
We don't have much patience when people are only reporting that they have x problem with boxer. Happened before...

collector wrote:

I wonder if this could be a starting point for Mac versions of my installers.

The AppleScript I started to do for that, does a similar approach but keeps out of the desktop to not clutter it. I used sone defined folders, did some checks, installed the test game...
Would just need someone with a lot of time to finish it for all games 😉

I've cleaned up the original AppleScript a bit (removing more things left over from an earlier project). My earlier project used a folder named "Printout" and a launch daemon that monitored that folder for files that it used for printing, sending commands to the host system, etc. None of this is useful for games, so I haven't spent much time adapting it for this new project. But it shouldn't be too difficult to make it work.

Dominus wrote:

collector wrote:

I wonder if this could be a starting point for Mac versions of my installers.

The AppleScript I started to do for that, does a similar approach but keeps out of the desktop to not clutter it. I used sone defined folders, did some checks, installed the test game...
Would just need someone with a lot of time to finish it for all games 😉

It took me a lot of time to do all of the Windows installers, so I understand the time aspect. However there are some games that are simple enough that a template can be made where only a list of the game files needs to be added to the script. The non CPC protected AGI and the SCI0 games need no special treatment.