#66 Win 95 api to in_win flag int 2F / 1231

[Stuart Axon]

A couple of patches to implement int 2F / 1231

This really doesn't do anything useful, except get one less error message before windows 9x fails to load.

[Stuart Axon]

Logged In: YES
user_id=1132071
Originator: YES

File Added: add_win95_check.diff

[Stuart Axon]

Logged In: YES
user_id=1132071
Originator: YES

Just re-uploaded fixed 2nd patch fix: use D_printf, not printf
File Added: add_win95_check.diff

[Bart Oldeman]

Logged In: YES
user_id=176505
Originator: NO

I'm leaving this open since it isn't so useful indeed, although there is nothing wrong with the patch as such.

I think getting Win9x to work in DOSEMU is a lot of work, and probably QEMU (and others) are a better solution for that now anyway.

[Julius]

Logged In: YES
user_id=679170
Originator: NO

It would be nice if Dosemu could work with Windows 9x similar to Win4Lin/Merge. Those also patched the MS Windows kernel, so that it didn't use certain instructions.

I noticed those kernel patches can be obtained from the RPMs here:
ftp://ftp.vbridges.com/pub/archive/9x/RPMS/i386

The patches to the MS Windows kernel are in:
(/)opt/win4lin/patch

Would this help getting MS Windows to run on Dosemu?

[Stas Sergeev]

Can we have only one flag, in_win31?
(possibly renaming it to in_win or something for win95 use)
With such a change the patch should be applied,
otherwise it is simply wrong. For instance, in_win31
is used in dpmi.c, and if it won't be set by win95, win95
will fail to work (yes, I know it will fail in either case :))

[Stuart Axon]

I've updated this with the suggestions below, and placed on the branch github here
https://github.com/stuaxo/dosemu-inwin-patch.git

• first commit changes the flag name to in_win from in_win31
• second commit implements the int.

Dug out a copy of win98 to see what happens.. not much :) - running 'win' from the dos 7 commandline still gets you to the "You may shut down" screen after some seconds.

[Stas Sergeev]

Could you please put the patch here as well?
I don't know how to quickly get the patch from
your git tree, without first cloning it entirely.
By the way, have you created this repo only
for that patch?

[Stuart Axon]

[Stuart Axon]

[Stuart Axon]

Looks like one could get the changes using this
http://stackoverflow.com/questions/5120038/is-it-possible-to-cherry-pick-a-commit-from-another-git-repository

Discovered git-format-patch and posted updated patches here though.

Git repository not needed now - it was just to share that patch (+ so I'd have access at different places).

[Stas Sergeev]

Thanks!
Sorry for my ignorance, but:
- what does "byte after" mean?
- RBIL says that "this function is not supported by DR-DOS 7.03 or earlier",
which suggests that it should be implemented in DOS, not in dosemu?
- If you only wanted to share the single patch, then
why to push the entire dosemu in a repo, and not just a patch? :)

[Stuart Axon]

Kind of silly to push the whole repo, but there you go.

The after byte bit full message is the one from RBI 'set byte after "IsWIN386" to 01h' - for reference to the list, not sure now if it should have the full text in it though.

Good catch on it only being supported in Win9x, there are some windows related functions in dosemu already it's hard (for me) to tell where the boundry lies.

Getting windows 9x to start up would be a bit ambitious (even in safe mode), however some DOS programmes enable features like LFN after checking for windows.

See also: http://www.spinics.net/lists/linux-msdos/msg01050.html

[Stas Sergeev]

Good catch on it only being supported in Win9x, there are some windows
related functions in dosemu already it's hard (for me) to tell where the
boundry lies.
I think it is going to be somehow supported in DOS,
because RBIL implies so saying "this function is not supported by DR-DOS 7.03 or
earlier", which means that it is supported in later.
I however do not understand what it does, at all.
Your patch only allows to set or clear this flag, but
how to test it??
Will it work if you just return NOCARRY, without any
flag at all?

[Stas Sergeev]

• LWORD(eax) = 0x0a03;
• LWORD(eax) = (win98 ? 0x0a04 : 0x0a03); / fake running Win98 /
  This makes more sense to me.
  Your patch doesn't seem to be doing this.
  I don't understand what your patch does, really. :)

[Stas Sergeev]

I guess you weren't receiving notifications because
SF was down yesterday.
Anyway, I changed the code in git a bit to make the
in_win31 flag private to DPMI.
Sorry for misleading you previously, but please use
the "win31_mode" flag instead.

[Stas Sergeev]

So any idea what this patch actually does?