If they're stored inside the DBGL.app package, do a right-click onto the app, choose 'Show packet content' (or similar) and look within the application package for the files.

Pan wrote:

From what I can tell, the configuration files and even the dosroot directory seem to be installed inside the DBGL.app file. I have no idea how to alter the files in an application package and I haven't seen any way to specify an alternative location for configuration files. Does anybody have any idea how I can migrate my entire DBGL configuration (including dosroot) so they can be used on the Mac?

Hi Pan,

Indeed, the standard DBGL distribution has all configuration and game data underneath its main folder. For Mac the means inside the DBGL.app folder.

This is not strictly necessary, for the DBGL 'data' directory can be configured to an alternative location if you like. DBGL uses a settings.conf properties file that allows you to set the DATA directory to, for example, ~/dbgldata in order to separate the settings/data from the application.
More information on the DATA folder is available here.

Hello, I've been using DBGL happily for many years, and have recently wanted to be able to maintain a definitive DBGL setup and […]
Show full quote

Hello, I've been using DBGL happily for many years, and have recently
wanted to be able to maintain a definitive DBGL setup and use backup
tools to keep them all synched. However, I have run into one problem:
portablilty.

I currently run linux, windows, and am looking at adding an apple PC
into my personal collection. And, while I can import and export each
setting, this is a bit of a hassle. Is it currently possible, or might
I be able to request a portable, OS-agnostic version of DBGL, so I can
synch DBGL and its contents across operating systems, or even store it
on an external hard drive and run it anywhere?

Interesting question. Since DBGL can use relative file locations, it runs just fine on a portable harddisk or memory stick; because the paths are relative, the driveletter or OS mountpoint to which the device is mapped makes no difference whatsoever. And since DBGL (beta) version 0.69a, it autodetects the required SWT library (matching the OS), so you should be able to start DBGL on each supported Operating System using that very same harddisk or memory stick if you simply put all the various swt??????.jar files in DBGL's lib folder.

So a single DBGL instance should run on the various OSs, and the data it creates should work on the different OSs, but what about DOSBox? Obviously, DOSBox versions differ somewhat among the supported architectures, but let's assume we're just using DOSBox 0.74 for a moment. I don't think you can put that DOSBox version for all 3 OSs on a single external hdd in a single partition, because, what filesystem would you have to give that hdd partition to have Linux and Windows and Mac to make the appropriate DB version executable? Please correct me if I'm wrong, but I think that's nearly impossible 😕 ?! Thus, it might make sense to have DBGL use a directory location on the actual OS filesystem as DOSBox location. To do that, simply edit the settings.conf and set dosbox=. to, for example, dosbox=~/dosboxversions
That would make DBGL look for all configured DOSBox versions in your ~/dosboxversions directory. Then, if you would create such a directory location on the 3 different OSs containing the DOSBox version for that OS, I think it should work alright. It would allow you to use the same DBGL instance on 3 different OSs without (hardly) any reconfiguration necessary on your hand to play the games in your list.

I'd be very interested if anybody could test such a scenario, and would strongly appreciate any feedback on this matter.

Regards,
Ronald

Hi everybody

Sorry for the delay, I seem to have 20 things to do and only time for 5 every day 😀

If they're stored inside the DBGL.app package, do a right-click onto the app, choose 'Show packet content' (or similar) and look within the application package for the files.

Indeed, the standard DBGL distribution has all configuration and game data underneath its main folder. For Mac the means inside the DBGL.app folder.

Thanks for this information. I'm still getting used to a Mac and some of the things that are done seem kinda weird from a Windows/Linux perspective. I hadn't realised that the .app files were actually directories and assumed they were some kind of compiled application packages. Anyway, simply copying a relevant set of files into the DBGL.app file resolved my problem 😀

I really love your highly portable application Ronald 😀

This is not strictly necessary, for the DBGL 'data' directory can be configured to an alternative location if you like. DBGL uses a settings.conf properties file that allows you to set the DATA directory to, for example, ~/dbgldata in order to separate the settings/data from the application.
More information on the DATA folder is available here.

Hmm, I gave this a try and it didn't work, it simply showed the blank configuration contained in the application, even though it was pointing at my DBGL Linux/Windows data settings. Those same settings worked when I copied them into the DBGL.app. Hang on, let me run another test...

Yes, copying the configuration out of the DBGL.app to ~/DBGL and then changing settings.conf in the DBGL.app only results in the profiles in DBGL.app being adjusted. The data parameter doesn't seem to change anything.

Interesting question. Since DBGL can use relative file locations, it runs just fine on a portable harddisk or memory stick; because the paths are relative, the driveletter or OS mountpoint to which the device is mapped makes no difference whatsoever. And since DBGL (beta) version 0.69a, it autodetects the required SWT library (matching the OS), so you should be able to start DBGL on each supported Operating System using that very same harddisk or memory stick if you simply put all the various swt??????.jar files in DBGL's lib folder.

Very nice! By the way, you might not remember this, but I was the guy who suggested the relative path idea way back then 😀 It was for the same reason, to aid mitgration across directories/drives/OS's etc 😀

So a single DBGL instance should run on the various OSs, and the data it creates should work on the different OSs, but what about DOSBox? Obviously, DOSBox versions differ somewhat among the supported architectures, but let's assume we're just using DOSBox 0.74 for a moment. I don't think you can put that DOSBox version for all 3 OSs on a single external hdd in a single partition, because, what filesystem would you have to give that hdd partition to have Linux and Windows and Mac to make the appropriate DB version executable? Please correct me if I'm wrong, but I think that's nearly impossible?!

I'm not sure if it's impossible. Does Windows need the executable bit set at all? I don't believe so, but I might be wrong. For Linux, can Java set the executable bit itself if the Dosbox version doesn't have it? I'm not sure if this is possible at all. For MacOS, I really have no idea 😀

Thus, it might make sense to have DBGL use a directory location on the actual OS filesystem as DOSBox location. To do that, simply edit the settings.conf and set dosbox=. to, for example, dosbox=~/dosboxversions
That would make DBGL look for all configured DOSBox versions in your ~/dosboxversions directory. Then, if you would create such a directory location on the 3 different OSs containing the DOSBox version for that OS, I think it should work alright. It would allow you to use the same DBGL instance on 3 different OSs without (hardly) any reconfiguration necessary on your hand to play the games in your list.

I'd be very interested if anybody could test such a scenario, and would strongly appreciate any feedback on this matter.

I'd be willing to help you try it, your application deserves support for sure. Give me a couple of days and I'll see what I can do.

Pan

And since DBGL (beta) version 0.69a, it autodetects the required SWT library (matching the OS), so you should be able to start DBGL on each supported Operating System using that very same harddisk or memory stick if you simply put all the various swt??????.jar files in DBGL's lib folder.

Hmm, it seems there is an immediate sticking point here, all the Java swt libs have the same name for all three operating systems. I'm not sure how DBGL references the files, so is simply renaming them safe or is some other tricky required?

Thanks

Pan

Pan wrote:

Hmm, it seems there is an immediate sticking point here, all the Java swt libs have the same name for all three operating systems.

Not since DBGL version 0.69a, where all swt jars are named differently for each architecture.

But anyways, there is a simpler, more flexible solution. Simply install DBGL on your different OS' and start it once. After closing DBGL, there will be a settings.conf file in your DBGL folder which you should open with your favorite text editor. Now let's assume you want to store your data (captures, profiles, game data) on a memory stick in e: (or /Volumes/USBSTICK on Mac or /Media/USBSTICK on Ubuntu). Therefor, create a directory on your memory stick, let's say e:\dbgl. Now, move the folders captures, db, dosroot, export, profiles, templates and xsl to that new location (see screenshot1). Then, change two lines in settings.conf:

1[database]
2connectionstring=jdbc:hsqldb:file:e:/dbgl/db/database
3
4[directory]
5data=e:/dbgl

Thus, instead of using the current directory (.) for the database and data folder, you have it point to your memory stick. Obviously, on a Mac installation your replace e: with /Volumes/USBSTICK, and on a Linux system you replace e: with something like /Media/USBSTICK .

If you use this solution, you have all your DBGL data in one place, while maintaining the flexibility to customize your DBGL installation on the various OS systems. For example, you can still use different system environment options (inside DBGL) on each OS. This allows you to set a specific SDL output renderer for each Operation System, for instance.

In the end, you can configure and play your DOS games on all systems using one familiar interface, without the need to export and/or import anything.

Regards,
Ronald