dosbox has a builtin version changing utiliy, for what it's worth:
"ver set 6" (or something like that)

wd wrote:

dosbox has a builtin version changing utiliy, for what it's worth:
"ver set 6" (or something like that)

Yes, you are right. But dosver.exe is intelligent.

e.g. through the dosver.exe, I can run the more.com in attachment directly, and I can't find which version I shsould set to run it through "ver set #".

thanks.

dosver is not intelligent, but has a list of filename to version settings.
Either open that dosver.exe which works with that more.com in some
hex editor and try to figure out the dos version it simulates (should be
close to the MORE.COM string), or use a debugger to check the dos
version calls, or use more.com from freedos if that works.
Or stick to the dosver thing you have of course 😀

I guess different DOS distribution has different "more.exe", they all have the same named app (more.exe), the apps working on different dos version.

e.g. the more.exe of dos ver 5.0 should not be permitted to run on dos ver 6.0, and vice versa.

So, for a program like more.exe, dosver.exe should has the ability to guess its working environment ( it's a 5.0 ver more.exe or a 6.0 ver more.exe, etc), then dosver.exe can simulates the proper working environment.

should has the ability to guess its working environment

No, they don't need/do any guessing, those are hardcoded tables.

How can hardcoded tables distinguish the same app of two versions ?

Does it like the AntiVirus program, it can distinguish them by analysing their "condition code" in the bin file. 😅

How can hardcoded tables distinguish the same app of two versions ?

Checksum? File Date?

wd wrote:

Checksum? File Date?

Oh, I see.

thank you.

By the way, you can use "ver set" in order to set the minor revision of DOS. E.g. if you'd like to set DosBox to DOS version 6.22 instead of version 6.0, you can use the following:

ver set 6 22

I'm not sure why the "ver set" is not documented though... I haven't found any reference to the exact version setting syntax in the Readme, so I found it by looking through the source code. Either way, it seems to do the job perfectly.

ver set doesn't always work though. I tried to use FDISK.EXE from my Win95-OSR2 CDROM in DOSBox 0.72, and FDISK refused to run due to incorrect DOS version. So it must check on something else than the reported DOS version.

fdisk doesn't work anyways, only if you boot into msdos

Gadget2006 wrote:

By the way, you can use "ver set" in order to set the minor revision of DOS. E.g. if you'd like to set DosBox to DOS version 6.22 instead of version 6.0, you can use the following:

ver set 6 22

Thanks.

Now my problem is focused on how to figure out the necessary DOS version of an App, like this MORE.EXE.

Maybe I just try the version numbers one by one. 😅

I've felt more should be a dosbox internal command, though a rather low priority. Being that freedos is gpl, could bundle its commands for the ones missing in dosbox so that there's full dos functionality from the get go.

You can download binaries with more included. I think Ykhwong's build includes more and also edit which is quite handy. There is no need of implementing more in Dosbox natively, as you can simply put existing programs into the Z: drive when building DosBox. Maybe contact Ykhwong and ask him how to do this.

ih8registrations wrote:

I've felt more should be a dosbox internal command, though a rather low priority. Being that freedos is gpl, could bundle its commands for the ones missing in dosbox so that there's full dos functionality from the get go.

Bundling them would mean that the DOSBox either had to 1) Make the source and building instructions available for down on dosbox.sf.net, 2) Get an agreement with the FreeDOS folks to refer them to their site for the downloads. Could be done I suppose, but who needs those commands? Those that do need them, probably already know how and where to get them.

And why in the Z drive? I have some FreeDOS stuff stuffed (!) away in a directory parallel to my games. Then in the autoexec-section of my configs, I do a mount X "\path\to\FreeDOS\stuff" and can access all the eXtra stuff with X:command. If you feel lazy, add the X:\ to the PATH in autoexec, and you are set.

You're missing it, that's how it's done now, and it's unecessary to put things in z, the point is to avoid having to do such. There is no need for most of the built in commands. With more, as with others, it's a matter of convenience, which is why it's a low priority, and a workable alternative that achieves the same convenience is to bundle the missing commands with the gpl freedos ones.