batocera-linux / batocera.linux

batocera.linux
https://batocera.org
Other
1.92k stars 494 forks source link

Game that requires a CD to run is not automatically mounted at startup #10292

Open velteyn opened 10 months ago

velteyn commented 10 months ago

Batocera build version

v38

Your architecture

x64 MiniPC Fujitzu Esprimo Q920

Your Graphic Processor Unit (GPU)

Integrated (e.g. Intel HD 550; RX Vega 8)

Graphical brand

Intel

Issue description

Hello I am trying to play Homeworld 2 from an iso CD. I did the installation from the windows_installer folder and everything went ok. When I tried to start the game this one asked me for the CD because it doesn't work without it. I attempted to add the CD via winecfg but found that winecfg is not present in the configuration tools. The game obviously does not start this way.

Expected result

Please add winecfg to be able to configure winwprefix properly.

Reproduction steps

1) Install Homeworld 2 via ISO (archive.org) 2) Sart the game 3) Game asks for CDrom, cannot start the game

Logs and data

No response

dmanlfc commented 10 months ago

wine doesn't currently mount the iso image to the d: drive when playing. this functionality will need to be added where a source .wine file or similar outlines to batocera there is an .iso to be mounted etc.

TronFNBlow commented 10 months ago

Any documentation / guide on how to do this?

Redemp commented 9 months ago

Best solution would be to use a No-CD exe file. Google "gamecopyworld" for an appropriate exe file for your version.

erichgoldman commented 9 months ago

I am facing the same issue where the game won't boot without the CD being present.

However, I am able to launch with the following workaround. Essentially go through the install process again since that seems to take care of the mounting process WITHOUT creating a new wineprefix

  1. Go to "Install a new Windows Game" in the ES GUI.
  2. Select the install drive
  3. There is NO blue screen, it just launches directly into the file manager GUI
  4. Here under "Computer" it will show the ISO mounted in D:
  5. You can then launch from the CD-Rom's launcher or go to the executable

Ideally, it would seem if there was just a way to run the installer again when you go to the game in the normal launcher it would take care of it.

I peaked into the code that does the install ISO which seems to be the logic to find and mount the ISO.

However, I cannot find enough documentation on how to run scripts before the launch of the executable under wine.

https://github.com/batocera-linux/batocera.linux/blob/ac1bd87b2208f200710aea34dd3d2bca076abd53/package/batocera/utils/batocera-wine/batocera-wine#L689-L720

Ideally, we could run a script that would mount the ISO and then create the appropriate link in dosdevices.

I am not sure how teardown works here or if there are any issues to consider. I wouldn't expect mounting the ISO and leaving it there until the system turns off has any big impact, but from some searching seems like wine shares the mount info or if it is just per wineprefix? Even if per-wineprefix we could script to unmount any other ISO (or the last ISO mounted with more logic) to then mount the next one needed.

in dosdevices I see a symlink

d: -> /var/run/win/[name of my iso].iso.cdrom

so I would wonder if there is any issue to just having all possible needed ISO's mounted?

I cannot find any documentation from wine that talks about just writing to file or a *.reg file to link the ISO. Would probably be better if wine could just use the ISO without it being mounted at the system level?

Another thought: I see in the directory structure of the wineprefix drive_c if you create a drive_d and just copy the ISO file will that be the same?

I noticed /userdata/roms/windows/[App Name].wine/drive_c/users/root/Desktop/Play [Name of Game].desktop

which I guess is just a config for launching if you have a WM/DE running. Unclear to me if this is actually what gets launched from the ES GUI or not. Maybe if this points to some script instead of the main executable?

I don't see anything in the wineprefix specific to batocera, so does batocera just run something my convention vs explicit configuration we can then later edit?

Is the autorun.cmd being run "inside" of wine with windows commands or is this a batch file that can run any linux shell code?

Any hints as to what should run and when, I can play around with the actual execution.

GB609 commented 4 months ago

This was the first thing i looked into after trying batocera (and forked to fix). Some pointers, infos and issues (the entire wine script is pretty unorganized with lots of duplicated code):

  1. Install_iso directly removes d: after starting 'wine explorer' which basically makes the 'd:' link a temporary file only visible to the running batocera-wine process. Once you navigate away from it in explorer, it is lost (unrelated bug, sorry).
  2. When a game shall be started, batocera does not directly delegate to wine from the ui. Batocera-wine is called and takes care of that by running into 'playWine' (or play_wine, not sure atm), which contains no mounting logic. This is the place where one could add more code or script calls.
  3. Install-iso and playWine are entirely separated pieces of code/function that know nothing of each other. If the current install would just create a link to the .cdrom directory during installation, the game would work until restart at best, because this directory is a mount point, not the actual iso (installiso would also need also need to be changed to NOT clean up after finishing). And this mount is not permanent. PlayWine would have to follow the 'd:' link, somehow get the original name 'somegame.iso.cdrom' from it, extract the name, search for the iso location in the fs and then mount it again.
  4. The autorun.cmd is 'parsed' in the batocera-wine script during playWine. It is basically just a badly named property file. The value of DIR is cd'd into, then CMD given as argument to wine. The path to the iso is not saved after/during install-iso.
  5. Just creating a symlink named d: to a mounted iso (or physical drive) is enough. The main problem is how to automate it and thus where to get the path and name of the iso.
  6. Copying the iso to drive_d is probably not enough. How do you do the copy? Just the files? In that case you'd loose the metadata thats placed in the iso9665 (or something) fs like disc serial etc. If you named (and moved) the iso itself as 'drive_d', wine would not know what to do with that binary file.

I have a few ideas on how to fix this:

  1. In my fork, i added a CDROM variable to autorun.cmd and included a generic mount function to take care of handling the iso (clean up/unmount not done yet, script still buggy). The place in install-iso which generates the autorun.cmd file then added the path accordingly. This is a generic approach.
  2. One could also extend playWine to look for and call special scripts in the game's directory. e.g. named game-init.sh/game-stop.sh and just hardcode the mount there on a per game basis. Or use the generic game start/end events and do some ifs on the system and game name to find out if it is a windows game needing a mounted iso (or combine that with a special properties file/marker whatever), then take care of it. I think the generic event hooks are the only way that does not require an overlay to the batocera system fs (aside from including the feature in bato directly).
  3. A few days ago i tested (just out of curiosity) if wine can take care of it itself and just symlinked 'dosdevices/d: -> path/to/game.iso' which surpisingly appeared to work, my game did start. But i havent tested if and how wine performs unmount/cleanup of the required loopback device. If wine does clean up properly this would be a very small and persistent workaround (or even the way to go forward instead of the current manual implementation of iso mounts). Not sure if that works outside x86_64 system and before bato 39 which i tested it with. Tested again, game runs completely fine even without disc. Error on my part
  4. Another one for hackers which i would not recommend: Instead of configuration, let playWine search an .iso file in windows_installers that has the same name as the game. Lots of file and string magic and maybe fuzzy logic required and too dependent on the assumption of fixed locations.