This type of game is way too complex for me 😉. I downloaded it somewhere to make the multiplayer work. Using the virtual nullmodem.

Don't be modest H-a-l. You know you're a genius. 😀

No dice still for me 🙁

This is what I've tried and still doesn't work under dos box (multiplayer and the 15 round limit)

1) Install in doxbox via downloaded file images
2) Other copies found on i-net (not many to find though)
3) Install on real dos machine, copy to xp machine (Used genuine copy of the game that I own)
4) Update game to V2.0 and try

Anyone else have any ideas? 🙁 I have a running dos machine that i can load up net drivers and hook up to my XP machine and copy the game off of. But it still didn't work. Very lost. 🙁

Ok. I got the source to DOSBox to compile and run. What I've found is that it wants the $$$STEAL.ME file to be missing when it looks to see if it exists, but when it checks for file attributes on the file, it wants to get them returned.

This may be some sort of OS issue for us HAL. Since you're running on win2k.

DOSBox checks if the file exists first:
case 0x4e:/* FINDFIRST Find first matching file */

Which it shouldn't find it (or expects not to find it) since it has the HIDDEN attribute flag.

Next,
case 0x43: /* Get/Set file attributes */

It does a GET and expects to have 32 (DOS_ATTR_ARCHIVE) returned to the attributes. Well It runs fine if these two conditions meet. Why DOSBOX isn't returning 34 (DOS_ATTR_ARCHIVE and DOS_ATTR_HIDDEN) I don't know.

My C++ and DOS programming skills are not good in the least. So I cannot fix it. While I could hack in a fix for just myself that checks if hte file name being checked is $$$steal.me and returns the attributes, and file missing conditions no matter what, it woulnd't work for others.

Is there a problem with DOSBox? Why is GC so unique in this case? Why does this work on WIN2k and not XP, Vista, WinServer08?
Hmm

To easily retest this case, just go straight to starting a new game and set one of the players to a REMOTE machine.

Thraka - Proper handling of file attributes in DOSBox is difficult due to the need for platform independence. If DOSBox is running on say Linux there is no place in the Linux filesystem to store attributes like ARCHIVE, HIDDEN or SYSTEM. It would have to be implemented with a hack, like creating a meta-file with the flags:

Real file: $$$STEAL.ME
Flags file: .meta-$$$STEAL.ME

Inside the meta-file DOSBox could store the corresponding flags, either as a simple 8-bit bitmap, or as a text string ("AHS").

It might be possible to get it to work if you used an image file for the C-drive in DOSBox, but it is a hassle to do it.

yeps crossplatform hidden is very hard.
readonly would be doable. but hidden is too tricky.

DOSBox could create an additional file in the directory which holds the attributes of the other files. Still some effort though.

Thanks for the replies guys. The .meta file seems like a good alternative. I'm a bit scared to implement it. But I guess it would be a bit fun to try 😀

Maybe something like you said, just straight text in the meta file. It could get more complex though for a long-term fix. Almost like a "game pack" that you drop into the dosbox folder and it tells dosbox about these situations, how to recognize and fix it.

Neat thoughts. 😀

h-a-l-9000 wrote:

DOSBox could create an additional file in the directory which holds the attributes of the other files. Still some effort though.

Just wondering. Could this attribute-file be a mini image-file? Either defaulting to some non-DOS name in the mounted directory, or specified as an extra parameter to the MOUNT command? Using a image-file could give you easy access to the necessary functions to shadow the real filesystem. Or?

We could improve the image file drive instead...

Thraka: Did you try to install and run that game on an image file (imgmount) at some point?
Might be easier to fix that one.

It wouldn't mount my floppy images I created so I had to extract them to the filesystem and treat that directory as a floppy drive and delete all content, paste in new content when I needed to swap disks.

I also just installed to the local filesystem, no hd image.

Really though DOSBox could generate that .meta file automatically anytime the emulation layer went to run the SetAttribute commands on a file. It would also defer to it (when it exists) for the GetAttribute calls. Then when the installer runs and sets those attributes (i think it may do that) on the file it would be recorded.

I hadn't even realized (or thought about) DOSBox mounting image files... I'm curious to see if it works that way instead. Not trying to get around the issue though, it would be nice to have a fix for normal file-system stuff.

Another idea would be to make a TSR that hooks INT 21 and modifies the attributes returned by function 43 for certain files. A config file with a list of files and the desired attributes would be the most general-purpose approach. This would also get around any cross-platform issues with DOSBox, I think.

In this case, it also needs to look for the file in a findfile, and not find it.

You can mount a harddisk image too. Reading attributes seems to work there, changing them doesn't. So far attributes only can be changed by booting DOS in DOSBox.

I just did a nullmodem local multiplayer against myself. You guys just don't know how happy I am right now. Extremely happy.

Based on Thraka's detective work, here is a small program to work around Global Conquest's issue in DOSBox. With the TSR loaded, the game is always told what it wants to hear in regards to the $$$steal.me file (cute name); resulting in a turn count of 30 instead of 15, and the initial stack overflow error with multiuser games doesn't occur. Works with both the original and 2.0 patch versions. Source code is included in the archive.

Wow! Thanks!!!!!!!!!

ripsaw, would it be possible to extend your tool to take the filename as a parameter? Maybe even a list of flags to be forced upon the file?

It's certainly possible to make something more generic; perhaps with a config file as I mentioned in my earlier post. However, Global Conquest also needed the file not to be find-able, because it's supposed to be hidden. It's a much larger issue getting the emulated DOS file functions to respect the file attributes than it is to simply report them on INT 21/4300.

Got it. One would need further modifications to DOSBox itself because it does not do an internal call-back to INT 21/4300 (whatever that is - and I hope I got the wording right with the call-back thing) when it initially searches for the file.