freedos-devel

[Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Steve N. <uso...@bu...>]

So I've had some thoughts regarding the MS-DOS 4 source drop, regarding 
things I'd like to do with the code.  I'm not really that good of a coder 
and probably would only be able to do some of them myself.  (I'd kill for 
a 3.3 drop - would obviate a lot of these things!  And 5 and 6.2 even 
more.)

First big issue, and one I can only partially resolve.  I'm taking a 
strict approach to the contents of the TOOLS folder - want to get rid of 
it and replace it with open-source equivalents.  That means, most 
practically, OpenWatcom 1.9 (there's prolly other options but the more 
like MSC it is the less torturous porting is going to be).  And the code's 
going to need to be dinked as far as possible to roll in Watcom instead of 
MSC - that's going to be a major pain in the neck.

Some of the code's pretty braindead, too.  Especially what looks to have 
come from IBM.  I mean...house styles vary, but Algolization is still just 
hideous-looking.  But it goes beyond that - think some of the utilities 
are going to need major rewrites.  I'm thinking of writing a new front-end 
around the FDISK code, but I haven't really been able to take the code and 
sort through everything to figure out what parts I'll need in order for 
FDISK to...fdisk (and don't know enough about int13, MBR or FAT to do it 
my damnself).  I was looking into D-Flat, but my brain melted - might have 
to write bespoke UI code.

Additionally, the whole "Message Server" thing.  (I think the broken TYPE 
command when COMMAND.COM is run under FreeDOS is related to this.)  I'd 
like to have the feature reduced to compatibility only and use good 
old-fashioned AH=9 like older DOS versions.  It'll probably also iron out 
some of the compile issues I've had trying to port the C stuff to Watcom!

After these things are ironed out, I guess the next phase would be, unless 
another code drop obviates the effort, to recreate features of later 
versions.  I've actually done this with some apps.  (The obvious question: 
Why not use what FreeDOS already has?  A: Because I'd like to have the 
entirety of the project under a single license - that being the X license 
Microsoft and IBM are already using.)  High memory support - big feature 
of 5.0 - that's a big part of why 5 was considered a _good_ version of DOS 
and 4 wasn't.

(If I sound like about an idiot, I probably sounded about ten times so on 
this list 20, 25 years ago... bear with me :P, I've been learning things 
and hope to continue to do so.)

-uso.

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Jim H. <jh...@fr...>]

On Fri, May 3, 2024, 10:53 PM Steve Nickolas via Freedos-devel <
fre...@li...> wrote:

> So I've had some thoughts regarding the MS-DOS 4 source drop, regarding
> [...]
> (The obvious question:
> Why not use what FreeDOS already has?  A: Because I'd like to have the
> entirety of the project under a single license - that being the X license
> Microsoft and IBM are already using.)
>


FYI: the license Microsoft has used for the official MS-DOS source code
releases is the MIT License. The FSF people call this the Expat license.

The FSF people also say the Expat/MIT license is compatible with the GNU
GPL. You can copy code from an Expat licensed project and paste it into a
GNU GPL'd project.

More info here:
https://www.gnu.org/licenses/license-list.en.html#Expat

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Steve N. <uso...@bu...>]

On Fri, 3 May 2024, Jim Hall via Freedos-devel wrote:

> On Fri, May 3, 2024, 10:53 PM Steve Nickolas via Freedos-devel <
> fre...@li...> wrote:
>
>> So I've had some thoughts regarding the MS-DOS 4 source drop, regarding
>> [...]
>> (The obvious question:
>> Why not use what FreeDOS already has?  A: Because I'd like to have the
>> entirety of the project under a single license - that being the X license
>> Microsoft and IBM are already using.)
>
> FYI: the license Microsoft has used for the official MS-DOS source code
> releases is the MIT License. The FSF people call this the Expat license.

Huh - thought they called it the "X11 license" (but then, that was 20 or 
25 years ago).  They have used it themselves.

> The FSF people also say the Expat/MIT license is compatible with the GNU
> GPL. You can copy code from an Expat licensed project and paste it into a
> GNU GPL'd project.

And thus MS-DOS 4 can theoretically (not really in practice) benefit 
FreeDOS.

-uso.

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Jim H. <jh...@fr...>]

On Fri, May 3, 2024, 11:19 PM Steve Nickolas via Freedos-devel <
fre...@li...> wrote:

> On Fri, 3 May 2024, Jim Hall via Freedos-devel wrote:
>
> [...]
>
> > The FSF people also say the Expat/MIT license is compatible with the GNU
> > GPL. You can copy code from an Expat licensed project and paste it into a
> > GNU GPL'd project.
>
> And thus MS-DOS 4 can theoretically (not really in practice) benefit
> FreeDOS.
>


Yes. I wrote an article about it when Microsoft released the earlier MS-DOS
under the same license:

https://opensource.com/article/18/10/microsoft-open-source-old-versions-ms-dos

>

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[E. C. M. <pu...@ul...>]

On at 2024-05-03 23:54 -0400, Steve Nickolas via Freedos-devel wrote:
> So I've had some thoughts regarding the MS-DOS 4 source drop, regarding 
> things I'd like to do with the code.  I'm not really that good of a 
> coder and probably would only be able to do some of them myself.  (I'd 
> kill for a 3.3 drop - would obviate a lot of these things!  And 5 and 
> 6.2 even more.)
> 
> First big issue, and one I can only partially resolve.  I'm taking a 
> strict approach to the contents of the TOOLS folder - want to get rid of 
> it and replace it with open-source equivalents.  That means, most 
> practically, OpenWatcom 1.9 (there's prolly other options but the more 
> like MSC it is the less torturous porting is going to be).  And the 
> code's going to need to be dinked as far as possible to roll in Watcom 
> instead of MSC - that's going to be a major pain in the neck.

As mentioned before, JWasm is probably going to be useful to replace the 
MASM v5.10 for this. Me, I'm working with the original toolchain for now 
even though it is (free but) closed source.

> Some of the code's pretty braindead, too.  Especially what looks to have 
> come from IBM.  I mean...house styles vary, but Algolization is still 
> just hideous-looking.  But it goes beyond that - think some of the 
> utilities are going to need major rewrites.  I'm thinking of writing a 
> new front-end around the FDISK code, but I haven't really been able to 
> take the code and sort through everything to figure out what parts I'll 
> need in order for FDISK to...fdisk (and don't know enough about int13, 
> MBR or FAT to do it my damnself).  I was looking into D-Flat, but my 
> brain melted - might have to write bespoke UI code.
> 
> Additionally, the whole "Message Server" thing.  (I think the broken 
> TYPE command when COMMAND.COM is run under FreeDOS is related to this.)  
> I'd like to have the feature reduced to compatibility only and use good 
> old-fashioned AH=9 like older DOS versions.  It'll probably also iron 
> out some of the compile issues I've had trying to port the C stuff to 
> Watcom!

The broken TYPE (and COPY) command in the shell is actually due to the 
Extended Attributes functions that the MS-DOS v4.01 kernel "supports". 
In fact, these functions are just placeholders that return an empty list 
and ignore all writes. I wrote about this to dosemu2 [1], as the TYPE 
and COPY commands were broken on dosemu2 redirector drives (even when 
running both command.com and the kernel from the MS-DOS release). The 
error is the command will (on FreeDOS) display "Extended Error 1" when 
trying to display a file using TYPE, or (on MS-DOS on a redirector 
drive) "Invalid function - <filename>". I patched command.com in my fork 
to not require these functions [2].

Writing of which, I also identicalised the binaries to both MS-DOS v4.00 
(matching the original release minus build fixes and encoding problems) 
[3] as well as the MS-DOS v4.01 release [4]. I compared the files to the 
content of disks found at the Internet Archive [5]. The v4.01 patch 
comes from hharte's fork on github [6], but I verified that it matches 
the v4.01 release. I also wrote about the process (regarding the v4.00 
work) on our forum [7]. The most difficult part involved creating a 
small unpacker utility for the select.dat files [8], to allow comparing 
the binary differences in the uncompressed data rather than being stuck 
with the compressed files.

An error that remains is that on the FreeDOS kernel, commands like "ver 
/r" and "mem /p" (using unsupported switches) will not display "Invalid 
switch" or "Invalid switch -  /p" but rather "Parse Error 3".

> After these things are ironed out, I guess the next phase would be, 
> unless another code drop obviates the effort, to recreate features of 
> later versions.  I've actually done this with some apps.  (The obvious 
> question: Why not use what FreeDOS already has?  A: Because I'd like to 
> have the entirety of the project under a single license - that being the 
> X license Microsoft and IBM are already using.)  High memory support - 
> big feature of 5.0 - that's a big part of why 5 was considered a _good_ 
> version of DOS and 4 wasn't.

I already added one MS-DOS v5 feature: Device drivers are passed the 
maximum valid address that they may allocate [9]. This allows loading 
lDebug as a device driver, albeit an lDebug bugfix is also needed [10].

Regards,
ecm


[1]: https://github.com/dosemu2/dosemu2/issues/2206
[2]: https://hg.pushbx.org/ecm/msdos4/rev/cf97c97c1d9b
[3]: https://hg.pushbx.org/ecm/msdos4/shortlog/63a05668c5f3
[4]: https://hg.pushbx.org/ecm/msdos4/rev/51ad27d225a8
[5]: https://archive.org/details/ms-dos-4.00-and-4.01
[6]: 
https://github.com/hharte/MS-DOS/commit/7e51e4249ee0e6185b4e3eed9902c5cf786f052a#comments
[7]: https://www.bttr-software.de/forum/forum_entry.php?id=21755
[8]: https://hg.pushbx.org/ecm/msdos4/rev/9a0f75e8c341
[9]: https://hg.pushbx.org/ecm/msdos4/rev/814a8eb71ce4
[10]: https://hg.pushbx.org/ecm/ldebug/rev/6c4bbd544091

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Bernd B. <ber...@bo...>]

Hello Steve,

> Some of the code's pretty braindead, too.  Especially what looks to 
> have come from IBM.  I mean...house styles vary, but Algolization is 
> still just hideous-looking.  But it goes beyond that - think some of 
> the utilities are going to need major rewrites.  I'm thinking of 
> writing a new front-end around the FDISK code, but I haven't really 
> been able to take the code and sort through everything to figure out 
> what parts I'll need in order for FDISK to...fdisk (and don't know 
> enough about int13, MBR or FAT to do it my damnself).  I was looking 
> into D-Flat, but my brain melted - might have to write bespoke UI code.

does the Microsoft FDISK provide a feature you are missing in Free 
FDISK, or is it because of the license thing you mentioned, or for pure 
fun? Writing a new frontend code for Microsoft FDISK would be a massive 
effort. This would probably take as long as a clean sheet design, and 
then it will still not handle large disks, FAT-32 and so on...

If you want to deal with partition managers, there is also the option of 
contributing to Free FDISK ;)

Greetings, Bernd

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Eric A. <e....@jp...>]

Hi!

Well, what is wrong with

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/fdisk.html

or alternatively

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/xfdisk.html

or even

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/aefdisk.html

to begin with?

FreeDOS fdisk seems to be quite okay including translations to
Turkish, German, Spanish, French and Swedish. It even mimicks
part of the user-unfriendliness of MS FDISK, yet still adding
features which Microsoft did not offer :-D

Cheers, Eric

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Steve N. <uso...@bu...>]

On Sat, 4 May 2024, Bernd Böckmann via Freedos-devel wrote:

> Hello Steve,
>
>> Some of the code's pretty braindead, too.  Especially what looks to 
>> have come from IBM.  I mean...house styles vary, but Algolization is 
>> still just hideous-looking.  But it goes beyond that - think some of 
>> the utilities are going to need major rewrites.  I'm thinking of 
>> writing a new front-end around the FDISK code, but I haven't really 
>> been able to take the code and sort through everything to figure out 
>> what parts I'll need in order for FDISK to...fdisk (and don't know 
>> enough about int13, MBR or FAT to do it my damnself).  I was looking 
>> into D-Flat, but my brain melted - might have to write bespoke UI code.
>
> does the Microsoft FDISK provide a feature you are missing in Free 
> FDISK, or is it because of the license thing you mentioned, or for pure 
> fun? Writing a new frontend code for Microsoft FDISK would be a massive 
> effort. This would probably take as long as a clean sheet design, and 
> then it will still not handle large disks, FAT-32 and so on...
>
> If you want to deal with partition managers, there is also the option of 
> contributing to Free FDISK ;)
>
> Greetings, Bernd

B and C (learning exercise + not really a fan of GPL).

I did go in figuring it might require a gutting, if only because the code 
is written in a mutant dialect of C that was partially algolized, and has 
limitations I'd need to lift.

-uso.

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Ralf Q. <fre...@gm...>]

On 5/3/2024 8:54 PM, Steve Nickolas via Freedos-devel wrote:
>
> First big issue, and one I can only partially resolve.  I'm taking a 
> strict approach to the contents of the TOOLS folder - want to get rid 
> of it and replace it with open-source equivalents.  That means, most 
> practically, OpenWatcom 1.9 (there's prolly other options but the more 
> like MSC it is the less torturous porting is going to be).  And the 
> code's going to need to be dinked as far as possible to roll in Watcom 
> instead of MSC - that's going to be a major pain in the neck. 

Sorry for being a bit late to this "party", but just some quick thoughts.

I don't think there is really a point in trying to get the whole thing 
compiled with FOSS tools. This is just a Sisyphos task, for no or very 
little gain. There is a reason why they included the old, matching tools 
in the release.

What could be however of value is to look at the source for some of the 
"trouble spots". For example, for me, the with FreeDOS supplied memory 
managers always give me a really hard time on real hardware. This 
release comes with the source of EMM/MEMM, which could help to glean 
some insights that could help to solve such memory issues. Or how EMM 
deals with DMA of various hardware, like sound cards, hard drive/floppy 
adapters or network adapters.


Ralf

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Steve N. <uso...@bu...>]

On Tue, 7 May 2024, Ralf Quint via Freedos-devel wrote:

> I don't think there is really a point in trying to get the whole thing 
> compiled with FOSS tools. This is just a Sisyphos task, for no or very 
> little gain. There is a reason why they included the old, matching tools 
> in the release.

I think it's actually somewhat of "in theory everything would work the 
same in practice; in practice not so."  The Watcom tools are explicitly 
clones of the Microsoft ones, but they're just different enough to throw 
the code.

The point is that in some circles (e.g., Debian) a program isn't truly 
open source unless the entire build can be done exclusively with open 
source software.

-uso.

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Aitor S. <ait...@gm...>]

Hi,


On Wed, 8 May 2024 at 04:19, Ralf Quint via Freedos-devel <
fre...@li...> wrote:

> On 5/3/2024 8:54 PM, Steve Nickolas via Freedos-devel wrote:
>
> Sorry for being a bit late to this "party", but just some quick thoughts.
>
I am even later...


> What could be however of value is to look at the source for some of the
> "trouble spots". For example, for me, the with FreeDOS supplied memory
> managers always give me a really hard time on real hardware. This
> release comes with the source of EMM/MEMM, which could help to glean
> some insights that could help to solve such memory issues. Or how EMM
> deals with DMA of various hardware, like sound cards, hard drive/floppy
> adapters or network adapters.
>
Or maybe to implement the VCPI?

Aitor

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Steve N. <uso...@bu...>]

On Fri, 16 Aug 2024, Aitor Santamaría via Freedos-devel wrote:

> Hi,
>
>
> On Wed, 8 May 2024 at 04:19, Ralf Quint via Freedos-devel <
> fre...@li...> wrote:
>

<snip>

>> What could be however of value is to look at the source for some of the
>> "trouble spots". For example, for me, the with FreeDOS supplied memory
>> managers always give me a really hard time on real hardware. This
>> release comes with the source of EMM/MEMM, which could help to glean
>> some insights that could help to solve such memory issues. Or how EMM
>> deals with DMA of various hardware, like sound cards, hard drive/floppy
>> adapters or network adapters.
>>
> Or maybe to implement the VCPI?
>
> Aitor
>

Is the EMM386 in MS-DOS 4.x new enough for that?

-uso.

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Ralf Q. <fre...@gm...>]

On 8/16/2024 1:43 AM, Steve Nickolas via Freedos-devel wrote:
> Or maybe to implement the VCPI?
>>
>> Aitor
>>
>
> Is the EMM386 in MS-DOS 4.x new enough for that? 
I haven't specifically looked for that, but given that the source code 
released is likely an early version of MS-DOS 4.0, it could be that this 
is not included.
At the company that I worked at in 1990 (1985 through 1994 overall), we 
had a version of a VCPI compatible CEMM (Compaq's EMS memory manager) 
provided for use with Compaq/MS-DOS 3.31, and also in early versions of 
QEMM and 386Max.
Just looked this actually up, and VCPI was first included by the 
internal memory manager of what would become Windows 3.0 (Windows386) 
and was part of EMM386.EXE (not .SYS!) released with DOS 5.0.

The "secret sauce" to include VPCI might be in the GEMMIS (Global EMM 
Import Specification) documentation and that wasn't publicly available 
back then (Novell (in)famously didn't get a copy of the specs)...


Ralf

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Steve N. <uso...@bu...>]

On Wed, 21 Aug 2024, Ralf Quint via Freedos-devel wrote:

> On 8/16/2024 1:43 AM, Steve Nickolas via Freedos-devel wrote:
>> 
>> Is the EMM386 in MS-DOS 4.x new enough for that? 
> I haven't specifically looked for that, but given that the source code 
> released is likely an early version of MS-DOS 4.0, it could be that this is 
> not included.
> At the company that I worked at in 1990 (1985 through 1994 overall), we had a 
> version of a VCPI compatible CEMM (Compaq's EMS memory manager) provided for 
> use with Compaq/MS-DOS 3.31, and also in early versions of QEMM and 386Max.
> Just looked this actually up, and VCPI was first included by the internal 
> memory manager of what would become Windows 3.0 (Windows386) and was part of 
> EMM386.EXE (not .SYS!) released with DOS 5.0.

Didn't think so (though see below).

> The "secret sauce" to include VPCI might be in the GEMMIS (Global EMM Import 
> Specification) documentation and that wasn't publicly available back then 
> (Novell (in)famously didn't get a copy of the specs)...

And IIRC we have... it's 386^MAX, right?... which supports it.  Such code 
couldn't be migrated directly into EMM386 without requiring it to get 
GNU'd, but concepts, perhaps, could.

Be nice to have a newer emm386, but that we have anything legitimately is 
a miracle already.

-uso.

Re: [Freedos-devel] [Semi-OT] Thoughts: Actually doing stuff with MS-DOS 4.01

[Aitor S. <ait...@gm...>]

Thanks for the tip!!

I've read as well in the thread (or some other thread) that JEMM386 already
implements VCPI (I wasn't aware of that).

Aitor


On Wed, 21 Aug 2024 at 21:41, Ralf Quint via Freedos-devel <
fre...@li...> wrote:

> On 8/16/2024 1:43 AM, Steve Nickolas via Freedos-devel wrote:
> > Or maybe to implement the VCPI?
> >>
> >> Aitor
> >>
> >
> > Is the EMM386 in MS-DOS 4.x new enough for that?
> I haven't specifically looked for that, but given that the source code
> released is likely an early version of MS-DOS 4.0, it could be that this
> is not included.
> At the company that I worked at in 1990 (1985 through 1994 overall), we
> had a version of a VCPI compatible CEMM (Compaq's EMS memory manager)
> provided for use with Compaq/MS-DOS 3.31, and also in early versions of
> QEMM and 386Max.
> Just looked this actually up, and VCPI was first included by the
> internal memory manager of what would become Windows 3.0 (Windows386)
> and was part of EMM386.EXE (not .SYS!) released with DOS 5.0.
>
> The "secret sauce" to include VPCI might be in the GEMMIS (Global EMM
> Import Specification) documentation and that wasn't publicly available
> back then (Novell (in)famously didn't get a copy of the specs)...
>
>
> Ralf
>
>
>
>
> _______________________________________________
> Freedos-devel mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>

[Freedos-devel] GEMMIS, Win3, 386MAX and SBEMU - was: Actually doing stuff with MS-DOS 4.01

[Eric A. <e....@jp...>]

Hi Ralf and Steve,

Our EMM386 has been supporting VCPI for quite a while ;-)

In ancient times, free EMM386 versions without VCPI existed.
Those were not even compatible with DOS extenders or DPMI
hosts (CWSDPMI, DPMIONE etc.) which was quite a limitation.

GEMMIS is a different story. It tells Windows that internal
state of EMM386 is structured exactly as Windows expects, so
it can import the state and replace the entire EMM386 in RAM
by something built into Windows itself, on the fly, which it
has to do in 386enh mode. WfW is no fun without 386enh mode,
Win3 was acceptable, Win9x is not even possible without it.

The easiest and most obvious solution to that problem is to
use the EMM386 for DOS which comes with Windows itself :-)

But only Windows cares about GEMMIS, no other apps do.

So while it would be nice to have something more modern
than MS EMM386 to use with MS Windows, you can still use
all Windows features by sticking to MS or other closed
source EMM386, or by just not loading any EMM386 at all.

https://en.wikipedia.org/wiki/EMM386#Overview

Regarding licenses, the mentioned Wikipedia article tells
us that DOSBOX and 386MAX both support GEMMIS, so we have
GPL2 and GPL3 licensed implementations of GEMMIS, which is
a lot better than having to rely on ancient MS DOS releases.

https://github.com/sudleyplace/386MAX/tree/main/386MAX

Look for the OEM_WIN3 case. It affects 45 source files :-/

In particular, "EMM Paging Import" stuff in 9 files matters,
but there also is Windows 3 UMB Instance data and more.

I believe 386MAX makes itself Win3 compatible on demand:
See im particular QMAX_IM2.ASM and QMAX_OVR.ASM which also
talks of the Win3 "unusual way in which V86MMGR..." :-p
It supports GPIS 1.11 with and GPIS 1.0 without UMB stuff.

The problem is that most drivers which are not MS EMM386
and do not want to limit themselves to the very same data
structures for state as MS EMM386 used have to calculate
structures looking like the MS ones to satisfy Windows.

Implementing EMM386 already is very challenging. Adding
GEMMIS support will make your code more ugly and complex.

Regards, Eric

PS: How about just using 386MAX if you prefer open source
instead of old MS EMM386 bundled with Windows? Yet another
method which avoids having to do huge updates in JEMM386.
386MAX also supports I/O trapping, nice for virtual SB16
style drivers, as MS EMM386 compatible int 2f.4a15 API :-)
Be aware that 386MAX has > 200 000 lines of ASM and INC :-o

Re: [Freedos-devel] GEMMIS, Win3, 386MAX and SBEMU - was: Actually doing stuff with MS-DOS 4.01

[Ralf Q. <fre...@gm...>]

On 8/21/2024 1:32 PM, Eric Auer via Freedos-devel wrote:
>
> Hi Ralf and Steve,
>
> Our EMM386 has been supporting VCPI for quite a while ;-)
better would be "some" VCPI suuport...
>
> In ancient times, free EMM386 versions without VCPI existed.
> Those were not even compatible with DOS extenders or DPMI
> hosts (CWSDPMI, DPMIONE etc.) which was quite a limitation.
That's why VCPI came into play...
> GEMMIS is a different story. It tells Windows that internal
> state of EMM386 is structured exactly as Windows expects, so
> it can import the state and replace the entire EMM386 in RAM
> by something built into Windows itself, on the fly, which it
> has to do in 386enh mode. WfW is no fun without 386enh mode,
> Win3 was acceptable, Win9x is not even possible without it.
>
> The easiest and most obvious solution to that problem is to
> use the EMM386 for DOS which comes with Windows itself :-)
>
> But only Windows cares about GEMMIS, no other apps do. 
That is NOT correct. GEMMIS was the interface to allow two (any two) 
memory managers to work together, nicely.
We had the GEMMIS specs back in those days due to the CAD software that 
we developed having its own memory manager and running in protected mode 
(first 80286, then 386), well before "memory managers" and "DOS 
Extenders" became a thing.
And our problem was that clients always ran into problems when they 
already had a (standard for their version of DOS) memory manager 
installed. That's why for some time, we worked rather closely with 
Compaq (one of our reseller in Switzerland at that time was also one of 
the largest Compaq retailers in Europe) as well as Quarterdeck and 
Qualitas. GEMMIS was the specs that defined how two memory managers 
could work along side each other, Windows was the initial case for 
Microsoft to come up with that specification, in order to have Windows 
in enhanced mode play along nicely. But there were other applications as 
well, not only our CAD system.

And the issue is not only for Windows, for example, to take over the 
memory management FROM EMM386 (or CEMM, QEMM, 386Max, ...) but when 
exiting, giving that memory management task and CPU state) BACK to DOS...


Ralf

Re: [Freedos-devel] GEMMIS, Win3, 386MAX and SBEMU - was: Actually doing stuff with MS-DOS 4.01

[Eric A. <e....@jp...>]

Hi Ralf,

> That is NOT correct. GEMMIS was the interface to allow two (any two) 
> memory managers to work together, nicely.

That is interesting to know, although it sounds like a very
specific use case. For classic DOS extenders, VCPI or DPMI
are enough. You can load DPMI providers using VCPI, or your
OS can directly provide DPMI without having to provide VCPI.

Your CAD software apparently needed something more powerful
than a DOS extender, given that it had to contain its very
own memory manager which then had to cooperate with others.

In the case of Windows, I would say multitasking is the
main difference between V86MMGR and EMM386, which forces
Windows to switch to a built-in memory manager while in
386enh mode, instead of just using/being a DOS extender.

> And the issue is not only for Windows, for example, to take over the 
> memory management FROM EMM386 (or CEMM, QEMM, 386Max, ...) but when 
> exiting, giving that memory management task and CPU state) BACK to DOS.

Sure, you want both aspects if you want GEMMIS. My doubt
is about who apart from Windows wanted GEMMIS. Of course
I am impressed that your CAD was one of those "whos" :-)

Do you have other specific examples of software containing
cooperating memory managers, beyond Windows and your CAD?

Regards, Eric

Re: [Freedos-devel] GEMMIS, Win3, 386MAX and SBEMU - was: Actually doing stuff with MS-DOS 4.01

[Liam P. <lp...@gm...>]

On Wed, 21 Aug 2024 at 21:34, Eric Auer via Freedos-devel
<fre...@li...> wrote:
>
> PS: How about just using 386MAX if you prefer open source
> instead of old MS EMM386 bundled with Windows?

I've tried it.

The snag is that in my testing it won't start on modern hardware.

QEMM386 (v8) and 386MAX fail to initialise and freeze the machine in
my testing on various models of Core 2 Duo and Core i5.

MS EMM386 and FreeDOS CEMM work fine.

I think the formerly-commercial ones try to do clever stuff with ROM
mapping and fail, probably due to race conditions in code that wasn't
written expecting to run on CPUs doing well over a gigahertz.

-- 
Liam Proven ~ Profile: https://about.me/liamproven
Email: lp...@ci... ~ gMail/gTalk/FB: lp...@gm...
Twitter/LinkedIn: lproven ~ Skype: liamproven
IoM: (+44) 7624 227612: UK: (+44) 7939-087884
Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053

Re: [Freedos-devel] GEMMIS, Win3, 386MAX and SBEMU - was: Actually doing stuff with MS-DOS 4.01

[tom e. <te...@dr...>]

>>
>> PS: How about just using 386MAX if you prefer open source
>> instead of old MS EMM386 bundled with Windows?

> I've tried it.

> The snag is that in my testing it won't start on modern hardware.

> QEMM386 (v8) and 386MAX fail to initialise and freeze the machine in
> my testing on various models of Core 2 Duo and Core i5.

> MS EMM386 and FreeDOS CEMM work fine.

> I think the formerly-commercial ones try to do clever stuff with ROM
> mapping and fail, probably due to race conditions in code that wasn't
> written expecting to run on CPUs doing well over a gigahertz.

VERY unlikely as "race conditions" require multitasking which they don't.
Btw, "race conditions" usually don't fail reliably, but rather like 10% random chanceof failure.

It's much more likely that they are surprised to see multi gigabyte sized memory.

But it's irrelevant to speculate as nobody is ever going do debug QEMM386 or 386MAX.

Tom

Re: [Freedos-devel] GEMMIS, Win3, 386MAX and SBEMU - was: Actually doing stuff with MS-DOS 4.01

[Liam P. <lp...@gm...>]

On 22/08/2024 5:31 pm, tom ehlert via Freedos-devel wrote:
> VERY unlikely as "race conditions" require multitasking which they don't.
> Btw, "race conditions" usually don't fail reliably, but rather like 10% random chanceof failure.

This seems like being excessively pedantic to me, but all right then: 
timing loops or something.

> It's much more likely that they are surprised to see multi gigabyte sized memory.

Possible. They work in VMs. I will try to experiment more.


> But it's irrelevant to speculate as nobody is ever going do debug QEMM386 or 386MAX.

386MAX is GPL3 FOSS now.

https://github.com/sudleyplace/386MAX


-- 
Liam Proven - Profile: https://about.me/liamproven
Email: lp...@ci... - Google Mail/Hangouts/Plus: lp...@gm...
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
IoM: +44 7624 227612 ~ UK: +44 7939-087884
ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: [Freedos-devel] GEMMIS, Win3, 386MAX and SBEMU - was: Actually doing stuff with MS-DOS 4.01

[tom e. <te...@dr...>]

Hallo Herr Liam Proven via Freedos-devel,

am Freitag, 23. August 2024 um 18:42 schrieben Sie:



> On 22/08/2024 5:31 pm, tom ehlert via Freedos-devel wrote:
>> VERY unlikely as "race conditions" require multitasking which they don't.
>> Btw, "race conditions" usually don't fail reliably, but rather like 10% random chanceof failure.

> This seems like being excessively pedantic to me, but all right then: timing loops or something.

Whatever, "race conditions" have a very specific mening in programming world.
As a non-programmer it's okay for you not to know what the meaning is, but it would be cool
to not use it in any public communication.


>> It's much more likely that they are surprised to see multi gigabyte sized memory.

> Possible. They work in VMs. I will try to experiment more.

+1


>> But it's irrelevant to speculate as nobody is ever going do debug QEMM386 or 386MAX.

> 386MAX is GPL3 FOSS now.

I know. But there wont be anybody experienced enough to do the debugging. You certainly wont be it.

Tom