While this discussion is miles away from my original proposal, I understand that my proposal with GSoC is buried. Thanks for this interesting discussion.
Your mouse-pusher.Willi
Sent: Friday, January 27, 2023 at 4:15 PM
From: "tom ehlert" <t...@drivesnapshot.de>
To: "Technical discussion and questions for FreeDOS developers." <freedos-devel@lists.sourceforge.net>
Subject: Re: [Freedos-devel] Google Summer of Code?
From: "tom ehlert" <t...@drivesnapshot.de>
To: "Technical discussion and questions for FreeDOS developers." <freedos-devel@lists.sourceforge.net>
Subject: Re: [Freedos-devel] Google Summer of Code?
Hallo Herr Liam Proven,
> I suppose my first suggestion would be: sod Windows.
> A suggestion of a justification:
> If people want a FOSS DOS then they must use a FOSS GUI, and if they
> want a proprietary GUI then they must accept that also means a
> proprietary DOS underneath.
this argument is nonsense. many/most people don't care about the 'open source'
part as long as it's free.
most care more if this OS supports big disks or much memory.
after all, an OS is not an end target:
people need the OS to run their applications like
1. Play classic DOS games.
2. Run legacy software.
3. Develop embedded systems.
none of this is open source.
> A BIOS:
> Well there is already at least one FOSS BIOS out there -- SeaBIOS.
> https://www.seabios.org/SeaBIOS
> https://en.wikipedia.org/wiki/SeaBIOS
> Surely that's a start?
I can't see many users to reprogram their motherboard (even if it
would be supported) just to play a casual round of Doom or
Wolfenstein.
> In other words, from EMM386 to JEMM to QEMM, they were already, 30
> years ago, 32-bit code that set up a hardware DOS VM and ran DOS in
> it.
whatever EMM386 and friends was and is, it is definitively not what
people think when they hear 'DOS VM'. you are abusing words to make a
point. not good.
> Yes, I know that how they got there was different. They didn't cold boot.
> What I am saying is that if UEFI can only load 32-bit (or 64-bit but
> that's irrelevant to DOS) payloads, well, if we're running DOS on a
> 32-bit machine, we more or less need one of those anyway. So, is there
> a way to use it?
> Write a special 32-bit payload that can only do one thing:
> 1. load into RAM
> 2. load a generic BIOS emulation which only emulates a few fixed
> devices that are supported by DOS
> 3. set up a single V86 session
> 4. boot FreeDOS into that
and would be so completely useless that it hurts.
no network card.
no mouse.
no USB devices.
(no memory at b8000 or a0000)?
no sound.
nothing with interrupts.
congratulations.
> Then FreeDOS loads some kind of shim that talks to the memory manager
> that is already resident. The DOS sessions in Windows NT and OS/2 ≥2
> both do this already. It is, or was, a thing.
actually still is; however you need a 32 bit installation of windows.
certainly good enough to Run legacy software. playing games very much
depends on the game.
Tom
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
> I suppose my first suggestion would be: sod Windows.
> A suggestion of a justification:
> If people want a FOSS DOS then they must use a FOSS GUI, and if they
> want a proprietary GUI then they must accept that also means a
> proprietary DOS underneath.
this argument is nonsense. many/most people don't care about the 'open source'
part as long as it's free.
most care more if this OS supports big disks or much memory.
after all, an OS is not an end target:
people need the OS to run their applications like
1. Play classic DOS games.
2. Run legacy software.
3. Develop embedded systems.
none of this is open source.
> A BIOS:
> Well there is already at least one FOSS BIOS out there -- SeaBIOS.
> https://www.seabios.org/SeaBIOS
> https://en.wikipedia.org/wiki/SeaBIOS
> Surely that's a start?
I can't see many users to reprogram their motherboard (even if it
would be supported) just to play a casual round of Doom or
Wolfenstein.
> In other words, from EMM386 to JEMM to QEMM, they were already, 30
> years ago, 32-bit code that set up a hardware DOS VM and ran DOS in
> it.
whatever EMM386 and friends was and is, it is definitively not what
people think when they hear 'DOS VM'. you are abusing words to make a
point. not good.
> Yes, I know that how they got there was different. They didn't cold boot.
> What I am saying is that if UEFI can only load 32-bit (or 64-bit but
> that's irrelevant to DOS) payloads, well, if we're running DOS on a
> 32-bit machine, we more or less need one of those anyway. So, is there
> a way to use it?
> Write a special 32-bit payload that can only do one thing:
> 1. load into RAM
> 2. load a generic BIOS emulation which only emulates a few fixed
> devices that are supported by DOS
> 3. set up a single V86 session
> 4. boot FreeDOS into that
and would be so completely useless that it hurts.
no network card.
no mouse.
no USB devices.
(no memory at b8000 or a0000)?
no sound.
nothing with interrupts.
congratulations.
> Then FreeDOS loads some kind of shim that talks to the memory manager
> that is already resident. The DOS sessions in Windows NT and OS/2 ≥2
> both do this already. It is, or was, a thing.
actually still is; however you need a 32 bit installation of windows.
certainly good enough to Run legacy software. playing games very much
depends on the game.
Tom
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
