Request: Better Win3 support?

[aorin1]

I've been using Pure for a few years now and it works great, the best DOS experience I've had and so easy to use. I'm wondering if it's possible that pure could work with the {REDACTED} (Admin: removed reference to piracy) somehow? Is it possible?

[schellingb]

Can you formulate your request more technical? What kind of features are you missing?

[aorin1]

Can you formulate your request more technical? What kind of features are you missing?

Currently, when we try an ExoWin3x0 game, and try to load it with Pure, it will show the folders from C: and D: as it tends to do with normal DOS games, as shown in the screenshot:

The Exo pack comes with the games zipped with a folder instead of all files in the root, and instead of C\:Windows, we get a C:\SIMC23X\, when trying to load it, the core will say it requires windows to run.

I'm sure I'm missing something here but my doubt is more like, how, if possible, can we run Win3x0 games as we do with the normal DOS games without requiring unzipping the original zip from the pack and messing with its structure.

[schellingb]

If you don't have WINDOWS in the ZIP file you are loading, then you won't have Windows, yes.

For bootable operating systems. like Windows 95 and 98, in DOSBox Pure since version 0.9.5 we have the [ Boot and Install New Operating System ] feature which installs an OS into a file that sits in the "System" directory of RetroArch.

I always thought it would be nice to have something similar for earlier, DOS based, Windows versions like Win3. I imagine you would have a ZIP file with just the WINDOWS directory inside System and then can load a ZIP with just the game. DOSBox Pure would then load both ZIPs, merge their structures into a single C: drive.

The only thing I'm stuck on is how to link up those two ZIPs. I guess, similar to the submenu available with [ Run Installed Operating System ] there would be another submenu [ Run System Shell ] (or something like that) and it would list up some specially named or specially marked ZIP files found in RetroArch's "System" directory. It is a bit lower priority than Windows 95/98 because you can just add Win3 to your games' ZIP file. But it would be nice to remove the need to do that if you have many Win3/2/1 games.

[aorin1]

If you don't have WINDOWS in the ZIP file you are loading, then you won't have Windows, yes.

For bootable operating systems. like Windows 95 and 98, in DOSBox Pure since version 0.9.5 we have the [ Boot and Install New Operating System ] feature which installs an OS into a file that sits in the "System" directory of RetroArch.

I always thought it would be nice to have something similar for earlier, DOS based, Windows versions like Win3. I imagine you would have a ZIP file with just the WINDOWS directory inside System and then can load a ZIP with just the game. DOSBox Pure would then load both ZIPs, merge their structures into a single C: drive.

The only thing I'm stuck on is how to link up those two ZIPs. I guess, similar to the submenu available with [ Run Installed Operating System ] there would be another submenu [ Run System Shell ] (or something like that) and it would list up some specially named or specially marked ZIP files found in RetroArch's "System" directory. It is a bit lower priority than Windows 95/98 because you can just add Win3 to your games' ZIP file. But it would be nice to remove the need to do that if you have many Win3/2/1 games.

The Win 95/98 approaches are really interesting. Yes, you explained it clearly enough so that I could understand how it works, at least the gist of it. While a few games are easy enough to fix manually, this request is mostly for frontend usage, specially since Pure provides a great "couch" experience and the amazing auto controller profiles, a bigger Win3x0 library would benefit a lot from what you suggest as a possible solution at the end of your last message. I understand that it would be similar to the 95/98 approach as it requires the base of Win3 to be present in the System directory.

[schellingb]

How would you expect to set this up though?

Would you read a document that tells you that you need to find a Windows 3 (or 3.1 or 3.11) installation and put it into a specially named .ZIP files inside RetroArch's 'System directory'?

Or alternatively, would you find a set of Windows 3 installation floppy disk images, mount the first one and have the start menu present you with an option [ Install System Shell ] which then runs you through the real Windows 3 installation to create that special file inside the System directory? That would be very similar to the [ Boot and Install New Operating System ] option we already have and would eliminate the need for much documentation. Just say "Load a real Windows installation disk set and go".

Obviously the second option is a bit more complex to implement but I feel like not many people read the documentation of a libretro core. And why would they... things really should "just work".

[aorin1]

I think the System zip approach is the simplest solution. Do you think it's easy to implement?

[schellingb]

Hmm, I'm just wondering what is it worth if no one will be able to use it (unless they read the documentation which basically no one does).

There still are some questions like what would the identifying key for such a ZIP file be. We can't just list any ZIP file in the System directory. So either it's every .DOSZ file, or every file named DOSBoxSystemShell*.zip. Or every file in a specific subdirectory.

Another would be changes made to the C:\WINDOWS directory while running a game. The changes will probably end up in the save game of the game, they wouldn't modify the prepared System zip. But someone might expect that, but that would be rather complex. Having modifications apply per-game would be useful though, could set the game to autostart or something and it won't affect other games.

Other than that... maybe not. We could also go for a 2 step implementation. Support loading of a specially named System zip first, and then later add a way to make this System zip inside DOSBox by mounting Windows 3 installation disks.

[aorin1]

That's true, this is not too simple. In any case, you're the one to choose the best option, and if you decide it, let me know how I can help.

[i30817]

I implemented my own bootleg autoboot windows 3.11 and 95 game version a few years ago, although I did some weird weird things for it, and it only worked in Linux.

I had my games in a squashfs file, compressed. I also had 3 windows, 2 windows 3.11 at different resolutions and a windows 95 hd image inside that squash.

I took special care that the windows 95 image was installed in a (dosbox made), hdd raw FAT16 file, so I could boot it of course. That windows when I installed it, I created a startup file that would invocate a fixed name startup file in 'd'

I had a copy-on-write overlay on the squashfs of course (prepared by a Linux launcher, code here, the dosbox I used also had some other patches Iike shaders - really liked the pixel perfect shader, mt32 and larger hdds), but since I didn't want to save modifications to the OS, whenever I started a windows game I mounted the Linux path /dev/shm (memory mapping) as a drive, mounted the os dir as another, copied over the os dir or file, unmounted both and mounted (raw if hdd) the game and OS. The game was installed to the d drive obviously.

On windows 3.11 I just started the shell with the game executable or bat as argument, and on windows 95, I just booted it (the autostart would boot).

For some reason, this startup method crashed diablo 1 (something something explorer copy protection). But it worked with a lot of windows 95 games, and I didn't have to care about scandisk errors with the OS (with the games, yes, since copy on write).

That got tiresome. If I was going to try again, I might try windows 95 with pagefile disabled or with 'always delete gamedisk modifications\overlay and depend on savestates', although I'm not sure if either would save data correctly without the modified game harddisk overlay.

Games that tried to change the os to introduce drivers or QuickTime were the bane of this setup, and I eventually ended up with a quite altered os image to appease all the games anyway.

Btw, 100% of the time I got a scandisk errors was because I got impatient and used altf4 to quit dosbox instead of waiting for windows to shutdown... so, that's a thing.

[i30817]

The most irritating thing of the setup above besides the scandisk on game drive is that for windows 95 games, since they had to be in a hdd file, the overlay would save modifications as the whole hdd file. It was only slow the first time, but it was a amazing waste of space in games like black dahlia, and took a extra 3 to 30 seconds it shouldn't (when I started this hack, I had a main rotational disk). Comparatively, windows 3.11 games since they could use the native to dos dosbox bridge, just saved the modified files and nothing else. I wish someone would do a windows 95\98 box with bootleg wine glued to a emulator already.

Or alternatively do some wizardry like the virtualbox guest additions to windows 98 so I could run games on a 'nfs' driver that just points to a native directory. And still autoboot of course. That one could actually solve the scandisk thing 😂

[schellingb]

All these use cases should be handled more conveniently by DOSBox Pure. Booted OS and system shell (Windows 3.11 and earlier) C: drive underlaying are very different things technically. This issue is about the system shell handling which does never present any issues with something like Windows 95's scandisk as it never leaves the DOSBox DOS layer which handles all file system access.

[i30817]

Ah well. I had a original point that got a bit obscured. It is 'if you install your own games, they don't need to be on c, and therefore you can separate them without the emulator merging zips for you'.

I can understand why you'd want a solution that doesn't require users to reinstall games though. Sounds like a extension of the overlay filesystem already in dosbox to support more than one level. Tricky.

[schellingb]

Yeah commit 6c7e1bf added the shared system shell support which underlays another ZIP file under the loaded game. So the C: drive then is composed of 3 layers:

• Shared system shell ZIP (read only)
• Game ZIP (read only)
• Save ZIP (read & write)

There can be even a 4th layer between the Game ZIP and Save ZIP which is a Patch ZIP which can modify content of the Game but it's not really used anywhere just yet. But it all works seamlessly.

The system shell stuff is not yet in a released version but it will be soon, it is already documented in the readme:

Shared system shells (like Windows 3)

If DOSBox Pure finds any .DOSZ zip files in the system directory of the frontend, they will get listed in the start menu under a sub-menu with the name [ Run System Shell ].

When a shell is selected, DOSBox Pure will underlay the content of the shell's DOSZ zip file as the base of the file system of the C: drive. This way, one installation of (for example) Windows 3.1 can be used for multiple games, keeping the Windows installation and games in separate ZIP files.

On startup it will look for any of the following files to automatically start the shell:

• C:\WINDOWS.BAT
• C:\AUTOEXEC.BAT
• C:\WINDOWS\WIN.COM

[i30817]

Can that autoboot windows 3.11 games? Because (unfortunately just for shells, not windows 95\98), passing the game executable \ shortcut \ bat file to windows will run it after 3.11 boot.

I usually use dosbox.conf files to boot dosbox and I'm a bit perplexed how to use those and DOSZ for systems without the menu. I'm fine with not using the menu, but it appears that there are at least some convinience features that require it? I don't suppose I can convince you to patch dosbox mount to accept zip files for this right? Edit: never mind this, unreasonable request, and I can always use the menu...

I'm also worried about having replaced a lot of DOS4GW by DOS32A for speed (among other hacks), so I doubt many games retropad autoconfig\dosbox speed setting will be recognized - maybe it's not so bad for protected mode games that would run as fast as possible in dosbox anyway?

Can the user force a retropad autoconfig like they can force a release year by including something (a hash?) in the zip filename? And if we can, how can we get the marker for the game?

[schellingb]

Again, the 3 layers with a system shell is the following:

• Shared system shell ZIP (read only)
• Game ZIP (read only)
• Save ZIP (read & write)

So once Windows 3.11 is started, a shortcut to the game can be put into the StartUp group. The StartUp group (C:\WINDOWS\STARTUP.GRP) is then saved into the Save ZIP. If desired, the file can be moved from the Save ZIP into the Game ZIP. Then, the shared system shell (i.e. Windows 3.11) can be marked as auto start in the DOSBox Pure start menu, it can be set with a "Skip Showing First X Frames". So with this, the entire startup of Windows 3 and the game will be fully skipped. The very first frame shown after selecting the game content in RetroArch will be the launched game. Windows 3 will not even be visible (if the game runs full screen).

Again not related to this issue, but automatic gamepad mapping doesn't rely on the existence of DOS4GW. A game is detected by seeing a game unique file (by checking the file name and file size). It often is not the game EXE file because there can be various patch versions of a game out there. Some games have multiple game-identifier files in the database.

Gamepad configuration and mapping has changed a lot since the last release. Please wait just a tiny bit more for the next update (unless you run your own builds from source). The README has a preview :-) Although selecting a preset from a game with a (huge) list is not in there but maybe that can be added.

[i30817]

I don't think a huge drop down is a great idea, seems unwieldly inside a core. Without a fuzzy search anyway.

Instead id prefer something like a crc32 I could put in the filename so the already major work you did to auto recognize games can be reused. Searching for the required crc can be done outside the UI, as long as there is something like a human readable mapping elsewhere.

And to be clear, id like this because I highly suspect many, but not all of my games will not be recognized automatically because of hacks (DOS32A being one, and one of those that can affect the executable(s)), it's not for all of them, unless I feel like it.

Doing it that way has the advantage it's hard to lose the 'configuration', even if it turns the filenames a bit uglier. Thumbnails I already use fuzzy search for.

[schellingb]

The search already is rather fuzzy. For example Duke Nukem 3D is recognized by the existence of a 188954 byte sized "DUKE.RTS", Jazz Jackrabbit is recognized by "SOUNDS.000" with 130603 bytes or Jetpack is recognized by either "JETPACK3.DAT" with 38840 bytes, "LEVEL01.DAT" with 506 bytes or "SCLM.DAT" with 54508 bytes. Having a means for users to contribute entries to the database (both identification and actual mapping) was always planned, maybe some day :-)

[toniosj]

I'm trying a Win3x game, Allied General, in 0.9.7 and I have this error:

[schellingb]

This has been fixed by a8c3d70 which will be in the next release. Currently github is blocking me from accessing my repository but as soon as that ends I plan to make a new release.

[toniosj]

Great @schellingb !!!

I'm so excited for this new version, the wait will surely have been worth it.

[i30817]

Btw I also had the startup group idea, but it doesn't apply to windows 95 hd images, which are opaque and not stackable (well I was intrigued by the qcow format, but nothing indicates dosbox would ever support it or its patch ability). So I ended using the 'startup group pointing to a bat file in d, pointing to the real game' in windows 95 images.

Can dosbox-pure stack windows 95 hdds? Or rather, can dosbox-pure boot windows 95 games and os in zip files without killing the disk or memory by requiring the unzip of the whole thing into a new bootable image?

I can imagine a really good VFS using zip files by only writing modifications to outside and reading files otherwise (id prefer squash because it doesn't have to start reading files from the start, but support of squash is so rare...), but I'd absolutely wouldn't trust zipped hd images copy on write that are supposed to be mounted in a real os (not the dosbox dos). My approach for it is terrible even without the zip (a modification of any file copies the whole hdd to the copy on write cache).

That of course is a multiple seconds pause disaster when booting a fmv game the first time. Wonder if you managed smaller writes for windows 95 games.

[schellingb]

A read-only OS image could theoretically be loaded from a IMG inside a ZIP, but there is no support for it for now. Because the default setting for the core option System > Advanced > OS Disk Modifications is to keep changes, it relies to being able to write them back to the IMG. Maybe we can scan for .IMZ files (compressed IMG files) and use them as read-only OS images.

Now in 0.9.8 there is the option to keep per game differencing disk for installed OS (documentation) (issue #423) which allows you to customize the OS per game. But keep in mind once you start using this option, you can never modify the base OS image again or any created per-content differences would not be usable anymore.

[i30817]

Mmm. That's what assumed would be the default. I dump the whole OS into memory just so I don't have to copy on write both it and the game, so the os always starts from the same base state.

Doesn't appear to cause problems (it actually solves them because scandisk never happens to the os 'drive') because the os will get its time from the emulator at boot, so no savegames created later appearing earlier or anything. I can't wait for winebox personally, just to get rid of this scandisk business even in the game drive.

Good to hear you managed a differentiating os disk (alongside the game I presume). How did you do it, are you creating a new hdd image combining the stacks? Kept in memory or file? And how are the modifications stored, the whole hd file or something like xdelta? Or the actual modified files by comparing inside the hdd to the base one after dosbox exits?

Id really enjoy in file accessed markers and 10kb savegames didn't force me to waste several gb in a fvm games, so I'm quite interested.

[schellingb]

This discussion is off topic for this issue, my response can be found in #423 Windows 3 style so called system shells are just underlays put to the regular DOS filesystem. Because there is no OS with raw hard disk sector access, there is no need for anything like disk images or differencing disks.

[schellingb]

@aorin1 I'm closing this issue now as the feature has been implemented as part of 0.9.8:

• Shared system shells (use one Windows 1/2/3 installation ZIP for multiple games) (documentation)

If there's any issues with the feature or something related, we can re-open the issue or just create a new one. Thanks for the request.