Re: [Freedos-devel] Google Summer of Code?

[Aitor Santamaría]

Hello,

On Sun, 29 Jan 2023 at 22:59, Jim Hall  wrote:

> I think Microsoft would have had to find a way around the obvious
> limitations in DOS, inherent in an operating system from 1981. With
> more powerful CPUs, more memory, and networking, you need a more
> powerful operating system. Let's call it "newDOS" and it is otherwise
> a "DOS" operating system: command line in text mode. New programs use
> a "newDOS" API, like any regular operating system. This "newDOS" also
> needs to provide multitasking, and a better memory model (flat memory,
> large address space, etc). "newDOS" also needs to provide a built-in
> network stack, so you don't have to keep loading drivers and
> configuring each application separately to talk to the network.
>

In my opinion, they actually did this. Pick Windows95, rename COMMAND.COM
to KRNL386.EXE (i.e. Windows) to avoid the GUI load into VM0 and there you
go a preemptive multitasking DOS with 32-bit device driver support and
virtual memory. No networking but I suppose someone can write a VNETD.VXD
device driver and you're done.

The magic is made by VMM32.VXD (formerly WIN386.EXE, formerly DOS386.EXE),
a highly evolved version of EMM386.EXE (hence the discussion in the other
thread whether EMM386 is a VMM or not: it is, but it is still a very
rudimentary one, as Tom pointed out). That's why in other threads I defend
that VMM32/VXDs are an evolved version of DOS and not Windows (unlike
NTOSKRNL, which is pure Windows), and that underneath the Windows 9X skin,
MS-DOS (a 32-bit version of MS-DOS) is beating.

Back to the supposed textmode version, if they had implemented the
Ctrl+Alt+Fn way of switching sessions, as in some earlier Linux
distributions, you could have had what you say, have Lotus 1-2-3 run in
VM1, WordPerfect in VM2...  (Ctrl+Alt+F1 or Ctrl+Alt+F2 to switch from one
to the other).

It is just that the popularity of GUIs made them prefer the Win32 API to
any kind of DOS extension API. Even the concept of DLL can survive in such
a 32-bit pure version of DOS without implying Windows. And if you are
mainly designed to run Win32 applications, use NT kernel instead of DOS.

Until Windows98 things seemed to go well: FAT32 support, LFN support, LBA
support. Then WindowsME came to commit suicide and killed this 32-bit line
of MS-DOS.

Aitor
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Liam Proven]

On Sun, 29 Jan 2023 at 22:59, Jim Hall  wrote:
>
> The thought experiment starts with: What might have happened if
> Microsoft had decided to keep "DOS" and not go the "Windows" route? A
> command line operating system, but one that takes advantage of newer
> hardware features?

Microsoft *did.* The product was released to a few customers in Europe
under the name "MS-DOS 4.0" and there are disk images out there. Then,
later, the efforts went into OS/2 and the name "MS-DOS 4" was reused
for the single-tasking product based on IBM PC DOS 4.0.

The original DOS 4 is described here:
http://www.os2museum.com/wp/multitasking-ms-dos-4-0-lives/

And here:
https://betawiki.net/wiki/Multitasking_MS-DOS_4

Here's a recent write-up from earlier this month:
https://virtuallyfun.com/2023/01/17/looking-back-at-ms-dos-4-00m-or-in-the-beginning-before-there-was-os-2/

You can run it in an emulator:
https://www.pcjs.org/software/pcx86/sys/dos/microsoft/4.0M/

This later morphed into CP-DOS:
https://www.os2museum.com/wp/before-os2-was-os2/

Which became "Football":
https://www.os2museum.com/wp/playing-football/

-- 
Liam Proven ~ Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Jim Hall]

Replying to my own comment:

On Sun, Jan 29, 2023 at 3:28 PM Jim Hall  wrote:
>[..]
> Sifting through the several conversation threads on this, I think the
> only project that would really be worth "Google Summer of Code" is a
> "loader" to boot FreeDOS on new machines.
[..]


This reminds me of a thought experiment I described several years ago.
Might have been part of a conference Q+A.

The thought experiment starts with: What might have happened if
Microsoft had decided to keep "DOS" and not go the "Windows" route? A
command line operating system, but one that takes advantage of newer
hardware features?

I think Microsoft would have had to find a way around the obvious
limitations in DOS, inherent in an operating system from 1981. With
more powerful CPUs, more memory, and networking, you need a more
powerful operating system. Let's call it "newDOS" and it is otherwise
a "DOS" operating system: command line in text mode. New programs use
a "newDOS" API, like any regular operating system. This "newDOS" also
needs to provide multitasking, and a better memory model (flat memory,
large address space, etc). "newDOS" also needs to provide a built-in
network stack, so you don't have to keep loading drivers and
configuring each application separately to talk to the network.

But to make these changes, you have a problem with running any legacy
16-bit DOS applications. These legacy programs expect to have direct
control of the hardware. Backwards compatibility is a Big Deal to
Microsoft, so they would have found a way to run them.

In this thought experiment, I imagine the "newDOS" with a kind of
"shim" that would run 16-bit DOS applications. Let's call the shim
"dos16" so it's clear. It's easy enough for the "newDOS" command
interpreter to discover if a program has, say, the "MZ" signature of a
16-bit DOS EXE. If the program you're trying to run is an MZ program,
the shell runs it inside "dos16" that makes the classic app think that
it's running on a 16-bit DOS with a BIOS, with 80x25 color text and
VGA 640x480 graphics.

It's easy enough to write a "dos16" host program that supports most
legacy DOS business applications like Lotus 1-2-3 and WordPerfect.
It's also not too hard to support many DOS games (harder if you want
SB16 and PC speaker emulation). It's much harder to support disk
utility programs and other programs that access the hardware directly
- but these are not likely to be useful in a "newDOS" system, so take
the easy route as "version 1." ("Version 1" of anything Microsoft
produced at the time was known to be incomplete anyway.) Build the
other support into "version 2" and later as needed.

Avoid loading a kernel in the "dos16" shim, it just runs the app.
There's no CONFIG.SYS and no AUTOEXEC.BAT. The shim uses environment
variables from the parent "newDOS" to set the environment for the
legacy 16-bit app.

So let's say you run Lotus 1-2-3 on "newDOS" like this:

newDOS:> 123

Then the "newDOS" detects a legacy DOS application, and instead runs
something like "dos16 123" behind the scenes. And the "dos16" is the
shim I described.


But if this sounds familiar, it's because this sort of exists today,
although it's not exactly as I've described it here. Think of Linux
(running in runlevel3) as the "newDOS" operating system and command
line environment, with a shim for classic DOS programs. The shim isn't
quite DOSBox, because DOSBox boots its own DOS kernel so you get a
partial DOS environment that legacy DOS games can run in. The
specifics are very different in this "shim" thought experiment, but
the general idea is the same. My thought experiment is probably closer
to DOSEmu's DEXE.

This is just a thought experiment of an alternative path that could
have been taken, if things had gone differently. But it would have
needed to start in the late 1980s. (And anyway, I happen to like Linux
for modern programs, and FreeDOS in a VM for classic DOS programs.
That works great for me.)


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Jim Hall]

On Fri, Jan 27, 2023 at 10:09 AM Wilhelm Spiegl  wrote:
>
> While this discussion is miles away from my original proposal,
> I understand that my proposal with GSoC is buried.  Thanks for this
> interesting discussion.


Sifting through the several conversation threads on this, I think the
only project that would really be worth "Google Summer of Code" is a
"loader" to boot FreeDOS on new machines. Liam described it in this
conversation: some kind of basic environment that makes it look like
FreeDOS is booting on 32-bit machine with BIOS, even though it's
booting in UEFI-only. We've also discussed something like this in
other conversation threads, a few years ago. It's also mentioned on
the "How to contribute" page on the wiki:
http://wiki.freedos.org/wiki/index.php/Contribute

Basically, provide some kind of boot environment that establishes its
own virtual environment in which FreeDOS can run.

This is not a new idea. I also wrote about an "inside the box" proposal in 2009:
https://freedosproject.blogspot.com/2009/04/inside-box.html

But from the discussion on the list, I think a "loader" is probably
the only idea that's a good project for GSoC.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Jim Hall]

On Sun, Jan 29, 2023 at 7:19 AM tom ehlert  wrote:
[..]
> 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.

Liam wrote: [response to #3 - embedded systems]
> > Not sure that's important in 2023. Any citations?

Tom wrote:
> http://wiki.freedos.org/wiki/index.php/Main_Page


To be fair, the wiki (and website) are outdated on this, since the
last survey. That's entirely on me. I plan to do the long-promised
website refresh, which will represent the use cases from the survey:

1. play classic DOS games
2. run classic DOS apps
3. develop DOS programs

This drops "embedded" in favor of writing new DOS programs. This is
because most of the people who replied to the survey are already
FreeDOS developers, or otherwise experimenting with DOS programming -
so that's not a surprise.

There's arguably a 4th use case: using FreeDOS to run a BIOS update.
But I'd argue those users aren't really installing FreeDOS to use
FreeDOS - they are using FreeDOS just to do the BIOS update, then they
are probably not going to use FreeDOS after that.


Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Steve Nickolas]

On Sun, 29 Jan 2023, tom ehlert wrote:


but I think the black box with the command prompt in Windows is indead
often called the DOS VM or DosBox.


DOS Virtual Machine, yeah.

-uso.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[tom ehlert]

>>> 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.

>> I don't really care. I am talking about how existing DOS 386 memory
>> managers have worked for 35+ years now.

>> The 80386 has hardware support for multiple concurrent DOS VMs. This
>> is called V86 mode. How *ALL* DOS 386 memory managers work is using
>> this features.

>> We cannot change the historical language now.

> I - as grandfather of FreeDOS EMM386 - may say that you are abusing
> 'DOS VM' when referring to what EMM386 does.

after rereading (and rethinking), I concede that 'DOS VM' is probably
correct.

I was just irritated because EMM386 actually does nothing beyond a
little memory mapping and implement DPMI, while a 'virtual machine'
like virtualPC, virtualBox, etc. does ininitively more.

but I think the black box with the command prompt in Windows is indead
often called the DOS VM or DosBox.

Tom





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[tom ehlert]

> I know. I am a professional in this field and have been since 1988.
> Please do me the courtesy of imagining that I know what I am talking
> about.

according to https://cz.linkedin.com/in/liamproven
FOSS and cloud reporter · Freelance writer and English teacher · Technical 
writer/editor ·
Software director · Customer Care Escalation Specialist · Technical Writer.


me, a professional *programmer* since 1983.

that's simply not the same level of experience.

Tom



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[tom ehlert]

>> 3. Develop embedded systems.

> Not sure that's important in 2023. Any citations?

http://wiki.freedos.org/wiki/index.php/Main_Page

>> 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.

> I don't really care. I am talking about how existing DOS 386 memory
> managers have worked for 35+ years now.

> The 80386 has hardware support for multiple concurrent DOS VMs. This
> is called V86 mode. How *ALL* DOS 386 memory managers work is using
> this features.

> We cannot change the historical language now.

I - as grandfather of FreeDOS EMM386 - may say that you are abusing
'DOS VM' when referring to what EMM386 does.




> That use case is already covered and so is irrelevant to this
> discussion, which I remind you is about how to boot DOS on a UEFI
> computer. You seem to have forgotten this.

according to your taste, install windows or linux.
then install DosBox.
start DosBox.
problem solved.

Tom




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Liam Proven]

On Fri, 27 Jan 2023 at 15:23, tom ehlert  wrote:
>
> this argument is nonsense. many/most people don't care about the 'open source'
> part as long as it's free.

I disagree. I think it's perfectly fair to say "FreeDOS does not
support MS Windows" and end it there.

> most care more if this OS supports big disks or much memory.

Not related to the above point.


> after all, an OS is not an end target:
> people need the OS to run their applications like
>
> 1. Play classic DOS games.

DOSbox covers this, easier and better.

> 2. Run legacy software.

DOSbox covers this, easier and with *much* better integration.

> 3. Develop embedded systems.

Not sure that's important in 2023. Any citations?

> none of this is open source.

This is false. Many games and a whole assortment of productivity apps
are either FOSS or freeware. Here is a site dedicated to that:

https://clasqm.github.io/freedos-repo/

> 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.

You misunderstand me so totally that I find it hard to imagine that
this is not intentional.

I am talking about a UEFI bootloader *which includes BIOS emulation*
using this existing FOSS BIOS.

I am not talking about reprogramming anyone's computers.

> 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.

I don't really care. I am talking about how existing DOS 386 memory
managers have worked for 35+ years now.

The 80386 has hardware support for multiple concurrent DOS VMs. This
is called V86 mode. How *ALL* DOS 386 memory managers work is using
this features.

We cannot change the historical language now.

> and would be so completely useless that it hurts.
>
> no network card.

Yep. This is DOS on 202x hardware. Networking won't work. Other OSes cover that.

> no mouse.

Probably yes, but emulation is possible.

> no USB devices.

Probably yes. DOS is the wrong OS if you want to use USB.

> (no memory at b8000 or a)?

Sorted out by the memory manager.

> no sound.

Yep. I don't think any modern sound card will work. We are talking
about a 1990s OS on 2020s hardware.

> nothing with interrupts.

The memory manager needs to map the lower 8 or 16 of them, and the
rest are for hardware unsupported by DOS anyway.

> congratulations.

You are blaming me for the fact that DOS can't support 202x computers?

I do not understand your thought processes or reasoning at all, and it
seems to me that you do not understand mine.

> actually still is; however you need a 32 bit installation of windows.

I know. I am a professional in this field and have been since 1988.
Please do me the courtesy of imagining that I know what I am talking
about.

> certainly good enough to Run legacy software. playing games very much
> depends on the game.

That use case is already covered and so is irrelevant to this
discussion, which I remind you is about how to boot DOS on a UEFI
computer. You seem to have forgotten this.

-- 
Liam Proven ~ Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Steve Nickolas]

On Fri, 27 Jan 2023, tom ehlert wrote:


this argument is nonsense. many/most people don't care about the 'open source'
part as long as it's free.


This.


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.


Often, "Windows 3.1x" is the #2.


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.


Also this.  (Though those, at least, can be rolled and run on modern 
systems.)



no network card.
no mouse.
no USB devices.
(no memory at b8000 or a)?
no sound.
nothing with interrupts.

congratulations.


The way I suggested to do things - a bare-metal emulator/virtualizer, upon 
which the FreeDOS kernel is run - is heavier than SeaBIOS, but would be a 
better fit for all of this.


Emulate a generic NIC, mouse, SVGA, SB16...run 16-bit code in emulation if 
you have to...and virtualize 32-bit stuff.


If the system's 32-bit, you can run DOS natively.  If the system's 64-bit, 
this would be for if you can't...if you can, just do.


(Hopefully that doesn't sound too confused.)

-uso.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Wilhelm Spiegl]

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" 
To: "Technical discussion and questions for FreeDOS developers." 
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 a)?
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

Re: [Freedos-devel] Google Summer of Code?

[tom ehlert]

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 a)?
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

Re: [Freedos-devel] Google Summer of Code?

[Liam Proven]

On Mon, 23 Jan 2023 at 18:55, Bret Johnson  wrote:

Hi Bret. Thanks for the long and considered reply.

I do not know why you conflated 2 different people's emails into one
reply, though, also stripping out the identifying info, but I will
only attempt to reply to the part that addressed my email.

> 
>
> > This is a very sketchy thought, but...
> >
> > AIUI, the way that 386 memory managers for DOS work is that they put
> > the CPU into protect mode, map RAM into upper memory blocks as DOS
> > wants, then start a single, non-multitasking V86 mode VM for DOS
> > itself.
> >
> > That basic process would be enough to boot a DOS instance, wouldn't
> > it?
>
> No, not really.  Before you can run a Memory Manager you need a BIOS and an 
> OS to install it on.

I am aware of that. :-) I am not proposing that an existing 386 EMM
could do this.

> > "All" it needs is a memory manager that can start as a 32-bit
> > process, set up a few interrupts -- INT 11 for the hard disk, for
> > instance -- start a single V86 process, and then kick DOS off in
> > that process. Then a stub program for DOS to load in CONFIG.SYS to
> > enable the memory manager.
>
> No, not quite.  For example, the way MS Windows worked (back before NT when 
> Windows was actually a DOS program) was that when Windows started it would 
> send a special call to EMM386 that told EMM386 to shut itself off.  Windows 
> would transfer a little bit of information from EMM386 (but it would NOT, 
> e.g., transfer the I/O virtualization information) and then would handle the 
> EMM386 stuff 'The Windows Way".  When Windows exited, it would tell EMM386 to 
> turn on again.  Exactly how that all worked was proprietary to MS which is 
> why other memory managers are incompatible with Windows.  Bob Smith and 
> Qualitas managed to work through some of those issues, but I'm not sure they 
> ever figured out the whole thing.  I do believe 386MAX was able to work with 
> Windows, at least partially.  BTW, this process was called GEMMIS (if you 
> want to try and look it up).

OK -- good info, and I will look it up.

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.

> > Normally, DOS starts EMM386 or JEMM386 or whatever. This way round,
> > JEMM386 starts DOS.
>
> Nice thought, but I don't think it will work.  You need much more than a 
> memory manager -- you really need a BIOS and an OS also.

Let's look at those separately.

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?

The questions become,
[1] is it, or can it be made, sufficiently generic?
[2] is there any way to softload the thing from a UEFI loader?

An OS:

Well, the point I was trying to make was that it doesn't need to be
very much of an OS.

While I am not arguing against your interesting rebuttal, which I
appreciate, I feel that you didn't engage with my core point. Perhaps
you conflated the 2 different emails from different people when
composing a response?

My core point was: the way that a 386 memory manager worked was
running as a kernel-mode 32-bit binary, running a single 386 hardware
V86 session.

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.

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

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.

-- 
Liam Proven ~ Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Louis Santillan]

On Sat, Jan 21, 2023 at 4:08 PM Jim Hall  wrote:

> So let's discuss:
>
> What core programs or components should we put into the application -
> if we apply and can get accepted?


For 386+ machines, what about an installer based on Linux that doesn’t need
to reboot multiple times to install to HDD?  Something that can initialize,
wipe, format, install mbr, setup dual boot systems more elegantly that MS
equivalent tools can.  Maybe something based on DOSLinux (
https://github.com/lpsantil/doslinux) if you want to reuse the current
installer boot support. A Linux based installer opens a possibility of a
ton of code to reuse.

Secondly, something I’ve been researching lately, a TSR web server.  A
small web server that hooks the packet driver interrupt, only listens for
packets from localhost to localhost, can retrieve files and execute CGI
scripts/binaries to do simple tasks.  This would make browsers like Links2,
MicroWeb, Arachne, Lynx potentially more useful.  It could open up
programming on DOS to folks who were too young to have grown up with DOS.
It could be used for things like installer, graphical package managers,
help files, graphical help files, file managers.

Lastly, collaboration with PCGEOS Breadbox/Ensemble project to improve and
bring the project into the FD distribution (
https://github.com/bluewaysw/pcgeos).
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Ralf Quint]

On 1/22/2023 11:30 PM, Robert Riebisch wrote:

Hi Liam,


"All" it needs is a memory manager that can start as a 32-bit process,
set up a few interrupts -- INT 11 for the hard disk, for instance --

INT 11?
Hard disk is Int 13h.

Yup, INT 11h is getting BIOS equipment list. Give him the benefit of a 
doubt that this just was a typo... ;-)



Ralf




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Jerome Shidel]

Hi Bret,

Yep! You said it all much better and in far greater detail than I went into. 

Thanks. :-)


Jerome


> On Jan 23, 2023, at 1:54 PM, Bret Johnson  wrote:
> 
> 
>> 
>> by the way, the 2 programs are the setup stuff and edlin. hardly
>> rocket science.
> 
> Even those two "simple" programs would probably be considered "rocket 
> science", or at least akin to "learning a foreign language", by most students 
> who are only used to modern technology and web apps.  Low-level stuff like 
> I/O and IRQ and BIOS emulation isn't flamboyant enough for most younger 
> people to get involved with these days.
> 
> 
> 
>> Perhaps it could be used to solve one of the most frequent problems
>> I hear. Running FreeDOS on modern UEFI hardware.
> 
> I think that is the main point of it all.
> 
>> As we are all well aware, this cannot be directly accomplished and
>> would require an abstraction layer between the OS and the actual
>> hardware.
> 
> It actually can, at least in certain situations.  The fundamental problem, at 
> least as I see it, is I/O.  I know a lot of the talk seems to be around sound 
> cards, but let's discuss it in terms of something a little simpler: joysticks.
> 
> A regular, old-fashioned joystick uses an I/O port, specifically port 201h.  
> There is also a BIOS function that lets you access the joystick, INT 15.84.  
> Over the years as computers got faster and joysticks got more complicated 
> (more buttons and axes), the INT 15.84 BIOS interface effectively became 
> useless.  Modern programs that want to use a joystick almost never use INT 
> 15.84 and instead try to talk to I/O port 201h directly.  That has caused all 
> kinds of problems.
> 
> Sound cards have a similar, yet slightly different, problem.  There was NEVER 
> a widely support BIOS-level interface for sound cards.  The de facto 
> "standards" that everyone seemed to base their sound card designs on were Ad 
> Lib and Sound Blaster which were fundamentally hardware (I/O) based and 
> proprietary (they also used things like DMA's and IRQ's).
> 
> Now, we're in a world where USB is pretty much the standard port for 
> everything plugged into the computer (certainly for joysticks and to a large 
> extent for sound devices).  From a hardware perspective, the USB host 
> controllers are the only things that actually talk to the "real" I/O ports 
> (sometimes PIO but usually MMIO).  DOS programs still expect to see the 
> joysticks on I/O port 201h and the sound cards at various I/O ports, but 
> those ports don't exist on the real hardware any more and must somehow be 
> virtualized.
> 
> The problem is even worse when you're using something like DPMI.  DPMI does 
> allow thunking down to the lower level (the DOS/16-bit "layer") for 
> interrupts but doesn't provide a standard way to thunk for I/O ports.  Since 
> a way to thunk I/O isn't provided, every single DPMI-based program needs to 
> understand things like USB and all the different kinds of devices that can be 
> USB-attached.  Of course, none of them understand USB and none of them thunk 
> the I/O, either.
> 
> It is possible to virtualize I/O in DOS with MS EMM386 and with Quailitas' 
> 386MAX.  JEMM also has a proprietary way to virtualize I/O with JLOAD, and I 
> am currently trying to add the MS/Qualitas-style capability to JEMM.  But 
> those methods will only work with programs that don't use DPMI or that thunk 
> the I/O from DPMI.  IOW, many old programs would need to be rewritten change 
> the way they do things to work properly on modern hardware without a VM.  
> That ain't gonna happen.
> 
> What a Virtual Machine does is provide another level of abstraction between 
> the real hardware (e.g., the I/O ports associated with the USB hardware) and 
> the virtualized hardware (e.g., I/O port 201h that a DPMI program is 
> expecting to see a joystick attached to).  With this extra layer of 
> abstraction, the DPMI program doesn't need to do the "thunking" -- it is 
> handled "automatically" by the abstraction layer that sits between the real 
> hardware (real I/O ports) and the virtualized hardware (virtualized I/O 
> ports).
> 
> That hardware abstraction layer is one of the main things that Virtual 
> Machines provide.  Of course, different VMs virtualize different hardware 
> devices.  I think they all do mice and keyboards and disks, a lot of them do 
> Ethernet cards and printers, but only some of them will do things like PC 
> Speakers and joysticks and sound devices.
> 
> One of the main things that Windows has done is to move the BIOS _function_ 
> (an abstraction layer between the hardware and the software) up into the OS 
> itself.  In fact, Microsoft at least used to call it the "Hardware 
> Abstraction Layer" or HAL, but I don't know if they still call it that or 
> not.  *nix does something similar -- they have hardware-specific drivers 
> (that talk to devices at the I/O level) and then have a "layer" that a 
> program "talks to" when it 

Re: [Freedos-devel] Google Summer of Code?

[Bret Johnson]

> by the way, the 2 programs are the setup stuff and edlin. hardly
> rocket science.

Even those two "simple" programs would probably be considered "rocket science", 
or at least akin to "learning a foreign language", by most students who are 
only used to modern technology and web apps.  Low-level stuff like I/O and IRQ 
and BIOS emulation isn't flamboyant enough for most younger people to get 
involved with these days.



> Perhaps it could be used to solve one of the most frequent problems
> I hear. Running FreeDOS on modern UEFI hardware.

I think that is the main point of it all.

> As we are all well aware, this cannot be directly accomplished and
> would require an abstraction layer between the OS and the actual
> hardware.

It actually can, at least in certain situations.  The fundamental problem, at 
least as I see it, is I/O.  I know a lot of the talk seems to be around sound 
cards, but let's discuss it in terms of something a little simpler: joysticks.

A regular, old-fashioned joystick uses an I/O port, specifically port 201h.  
There is also a BIOS function that lets you access the joystick, INT 15.84.  
Over the years as computers got faster and joysticks got more complicated (more 
buttons and axes), the INT 15.84 BIOS interface effectively became useless.  
Modern programs that want to use a joystick almost never use INT 15.84 and 
instead try to talk to I/O port 201h directly.  That has caused all kinds of 
problems.

Sound cards have a similar, yet slightly different, problem.  There was NEVER a 
widely support BIOS-level interface for sound cards.  The de facto "standards" 
that everyone seemed to base their sound card designs on were Ad Lib and Sound 
Blaster which were fundamentally hardware (I/O) based and proprietary (they 
also used things like DMA's and IRQ's).

Now, we're in a world where USB is pretty much the standard port for everything 
plugged into the computer (certainly for joysticks and to a large extent for 
sound devices).  From a hardware perspective, the USB host controllers are the 
only things that actually talk to the "real" I/O ports (sometimes PIO but 
usually MMIO).  DOS programs still expect to see the joysticks on I/O port 201h 
and the sound cards at various I/O ports, but those ports don't exist on the 
real hardware any more and must somehow be virtualized.

The problem is even worse when you're using something like DPMI.  DPMI does 
allow thunking down to the lower level (the DOS/16-bit "layer") for interrupts 
but doesn't provide a standard way to thunk for I/O ports.  Since a way to 
thunk I/O isn't provided, every single DPMI-based program needs to understand 
things like USB and all the different kinds of devices that can be 
USB-attached.  Of course, none of them understand USB and none of them thunk 
the I/O, either.

It is possible to virtualize I/O in DOS with MS EMM386 and with Quailitas' 
386MAX.  JEMM also has a proprietary way to virtualize I/O with JLOAD, and I am 
currently trying to add the MS/Qualitas-style capability to JEMM.  But those 
methods will only work with programs that don't use DPMI or that thunk the I/O 
from DPMI.  IOW, many old programs would need to be rewritten change the way 
they do things to work properly on modern hardware without a VM.  That ain't 
gonna happen.

What a Virtual Machine does is provide another level of abstraction between the 
real hardware (e.g., the I/O ports associated with the USB hardware) and the 
virtualized hardware (e.g., I/O port 201h that a DPMI program is expecting to 
see a joystick attached to).  With this extra layer of abstraction, the DPMI 
program doesn't need to do the "thunking" -- it is handled "automatically" by 
the abstraction layer that sits between the real hardware (real I/O ports) and 
the virtualized hardware (virtualized I/O ports).

That hardware abstraction layer is one of the main things that Virtual Machines 
provide.  Of course, different VMs virtualize different hardware devices.  I 
think they all do mice and keyboards and disks, a lot of them do Ethernet cards 
and printers, but only some of them will do things like PC Speakers and 
joysticks and sound devices.

One of the main things that Windows has done is to move the BIOS _function_ (an 
abstraction layer between the hardware and the software) up into the OS itself. 
 In fact, Microsoft at least used to call it the "Hardware Abstraction Layer" 
or HAL, but I don't know if they still call it that or not.  *nix does 
something similar -- they have hardware-specific drivers (that talk to devices 
at the I/O level) and then have a "layer" that a program "talks to" when it 
wants to send or receive data from some particular device.  The program doesn't 
need to know what kind of hardware port the device is attached to.

DOS has always expected that abstraction layer to be provided by the BIOS.  For 
example, if you use the BIOS INT 13h function for disk access you don't need to 
know if the DISK is MFM/RLL, 

Re: [Freedos-devel] Google Summer of Code?

[jerome]

Hi, 

> On Jan 22, 2023, at 4:37 PM, Liam Proven  wrote:
> 
> On Sun, 22 Jan 2023 at 22:11, Jerome Shidel  wrote:
>> 
>> Assuming Google does not scrap GSoC amidst the layoffs, I have a thought.
>> 
>> Perhaps it could be used to solve one of the most frequent problems I hear. 
>> Running FreeDOS on modern UEFI hardware.
>> 
>> As we are all well aware, this cannot be directly accomplished and would 
>> require an abstraction layer between the OS and the actual hardware.
> 
> I was discussing this recently on Mastodon, following Jim kindly
> agreeing to a video interview  for the Register.
> 
> https://social.vivaldi.net/@do...@nd2.uk/109716078029851572
> 
> This is a very sketchy thought, but...
> 
> AIUI, the way that 386 memory managers for DOS work is that they put
> the CPU into protect mode, map RAM into upper memory blocks as DOS
> wants, then start a single, non-multitasking V86 mode VM for DOS
> itself.
> 
> That basic process would be enough to boot a DOS instance, wouldn't it?
> 
> "All" it needs is a memory manager that can start as a 32-bit process,
> set up a few interrupts -- INT 11 for the hard disk, for instance --
> start a single V86 process, and then kick DOS off in that process.
> Then a stub program for DOS to load in CONFIG.SYS to enable the memory
> manager.
> 
> Normally, DOS starts EMM386 or JEMM386 or whatever. This way round,
> JEMM386 starts DOS.
> 
> Does that seem doable?
> 
> It needs to be small, but as such, I wonder if VisOpySys, KolibriOS,
> MenuetOS or the like might have something usable?
> 
>> A project could be created to provide a very thin Linux based system 
>> (possibly using an RTOS kernel) whose only job is to manage the abstraction 
>> layer and implement the virtual machine to run FreeDOS.
> 
> This sounds akin to the process HP and others use to ship FreeDOS laptops.
> 
> It works but it's quite complicated:
> 
> https://blog.tmm.cx/2022/05/15/the-very-weird-hewlett-packard-freedos-option/ 
> 

There are many similarities. But, overall not really. 

Basically, HP is just running linux and starting a Virtual Machine image that 
has FreeDOS installed. For all purposes, it is just linux faking DOS using a 
Virtual Machine. There isn’t anything wrong with that. But, it is not what I’m 
thinking. 

I'm thinking more along the lines of how SYSLINUX / MEMDISK work, which we use 
on the LiveCD to boot FreeDOS on more recent hardware that have problems with 
the LegacyCD. The LegacyCD just uses the original El Torito specification 
without SYSLINUX/MEMDISK. All BIOS based systems should boot the LegacyCD. But, 
that is not the case. Many modern machines fail to boot it. I think that is 
probably caused by lack of testing or only partial implementation of the spec 
on their part. Similar to PC speaker support in most Virtual Machine platforms, 
it may just not be there. 

There could be a small image containing a thin linux host that is booted by 
system. Possibly in it’s own partition or image file. This host then provides 
an abstraction layer which then boots the system like it was a PC with a legacy 
BIOS. Most likely providing a some abstracted and emulated hardware like a 
SoundBlaster compatible audio card. The Client OS (FreeDOS) would be installed 
to a normal partition on the drive. 

Providing support to also map things like I/O ports from the host OS to the 
client, to allow the possibility of connecting real legacy hardware  to the 
machine (like CNC machines and TTY devices).

:-)

Jerome

On a side note... I think we should probably discontinue the LegacyCD. There is 
only a very narrow range of hardware that can boot the LegacyCD but cannot boot 
the LiveCD. That hardware has an extremely high probability it will also have a 
1.44 floppy diskette drive. That floppy drive can be used to boot the LiveCD. 
Like I said, it is a very small range of hardware and would effect very few 
users. It is more effort to maintain, distribute and explain than it is worth. 
Also, it would eliminate any confusion on “which” CD image to download. The 
user would just download the LiveCD and either it boots directly or they use 
the included floppy boot image. 


> 
> -- 
> Liam Proven ~ Profile: https://about.me/liamproven
> Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
> Twitter/LinkedIn: lproven ~ Skype: liamproven
> UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
> 
> 
> ___
> 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

Re: [Freedos-devel] Google Summer of Code?

[Robert Riebisch]

Hi Liam,

> "All" it needs is a memory manager that can start as a 32-bit process,
> set up a few interrupts -- INT 11 for the hard disk, for instance --

INT 11?
Hard disk is Int 13h.

Cheers,
Robert
-- 
BTTR Software   https://www.bttr-software.de/
DOS ain't dead  https://www.bttr-software.de/forum/


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Liam Proven]

On Sun, 22 Jan 2023 at 22:11, Jerome Shidel  wrote:
>
> Assuming Google does not scrap GSoC amidst the layoffs, I have a thought.
>
> Perhaps it could be used to solve one of the most frequent problems I hear. 
> Running FreeDOS on modern UEFI hardware.
>
> As we are all well aware, this cannot be directly accomplished and would 
> require an abstraction layer between the OS and the actual hardware.

I was discussing this recently on Mastodon, following Jim kindly
agreeing to a video interview  for the Register.

https://social.vivaldi.net/@do...@nd2.uk/109716078029851572

This is a very sketchy thought, but...

AIUI, the way that 386 memory managers for DOS work is that they put
the CPU into protect mode, map RAM into upper memory blocks as DOS
wants, then start a single, non-multitasking V86 mode VM for DOS
itself.

That basic process would be enough to boot a DOS instance, wouldn't it?

"All" it needs is a memory manager that can start as a 32-bit process,
set up a few interrupts -- INT 11 for the hard disk, for instance --
start a single V86 process, and then kick DOS off in that process.
Then a stub program for DOS to load in CONFIG.SYS to enable the memory
manager.

Normally, DOS starts EMM386 or JEMM386 or whatever. This way round,
JEMM386 starts DOS.

Does that seem doable?

It needs to be small, but as such, I wonder if VisOpySys, KolibriOS,
MenuetOS or the like might have something usable?

> A project could be created to provide a very thin Linux based system 
> (possibly using an RTOS kernel) whose only job is to manage the abstraction 
> layer and implement the virtual machine to run FreeDOS.

This sounds akin to the process HP and others use to ship FreeDOS laptops.

It works but it's quite complicated:

https://blog.tmm.cx/2022/05/15/the-very-weird-hewlett-packard-freedos-option/

-- 
Liam Proven ~ Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Steve Nickolas]

On Sun, 22 Jan 2023, Jerome Shidel wrote:

Assuming Google does not scrap GSoC amidst the layoffs, I have a 
thought.


Perhaps it could be used to solve one of the most frequent problems I 
hear. Running FreeDOS on modern UEFI hardware.


As we are all well aware, this cannot be directly accomplished and would 
require an abstraction layer between the OS and the actual hardware.


A project could be created to provide a very thin Linux based system 
(possibly using an RTOS kernel) whose only job is to manage the 
abstraction layer and implement the virtual machine to run FreeDOS.


This could be done almost transparently. Booting straight to DOS unless 
the user pressed a specific key (Like F1) during boot.


Pressing such a key would bring up a BIOS like interface that could be 
used to change the virtual BIOS settings and configure drivers and such 
aspects of the host OS.


Their job would be to create that interface and make it all work 
seemingly. Most of the pieces required exist. But, it would not be a 
small task to implement.


It could yield much better performance and more accurate emulation than 
traditional virtual machines. With todays multi-core systems, individual 
cores could be dedicated to emulating various aspects of PC hardware. 
For example, one core could be dedicated to performing the tasks handled 
by a sound card.


I think such a project could appeal to many. There is a lot of interest 
in playing old games. Also, since this would be a generic legacy PC 
emulation layer. It could be used to install other Operating Systems 
like MS-DOS, PC-DOS, etc.


:-)

Jerome


I think I actually proposed a similar idea some time ago except that it 
was *itself* the OS, rather than a stripped-down Linux distro.  Sort-of a 
pre-AMD64 PC emulator, virtualizing where possible, emulating where not.


Then again, I have a half-written Apple //e emulator that runs straight 
off UEFI - and it's much the same thing I was describing, except Apple ][ 
instead of an older variety of PC, and strictly emulation.


I do feel it's really overkill though - and it's a bit of a two-edged 
sword.  More work to implement and maintain, though much less of a 
footprint.


As for all the people saying "make FreeDOS more like Linux", they don't 
seem to understand FreeDOS *or* Linux.


-uso.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Jerome Shidel]

Assuming Google does not scrap GSoC amidst the layoffs, I have a thought.

Perhaps it could be used to solve one of the most frequent problems I hear. 
Running FreeDOS on modern UEFI hardware.

As we are all well aware, this cannot be directly accomplished and would 
require an abstraction layer between the OS and the actual hardware. 

A project could be created to provide a very thin Linux based system (possibly 
using an RTOS kernel) whose only job is to manage the abstraction layer and 
implement the virtual machine to run FreeDOS. 

This could be done almost transparently. Booting straight to DOS unless the 
user pressed a specific key (Like F1) during boot. 

Pressing such a key would bring up a BIOS like interface that could be used to 
change the virtual BIOS settings and configure drivers and such aspects of the 
host OS.

Their job would be to create that interface and make it all work seemingly. 
Most of the pieces required exist. But, it would not be a small task to 
implement.

It could yield much better performance and more accurate emulation than 
traditional virtual machines. With todays multi-core systems, individual cores 
could be dedicated to emulating various aspects of PC hardware. For example, 
one core could be dedicated to performing the tasks handled by a sound card. 

I think such a project could appeal to many. There is a lot of interest in 
playing old games. Also, since this would be a generic legacy PC emulation 
layer. It could be used to install other Operating Systems like MS-DOS, PC-DOS, 
etc.

:-)

Jerome

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Emir SARI via Freedos-devel]

Hello,

It is a good idea to apply to GSoC; but I reckon there won’t be many students 
to select it. It sounds like giving a toddler a broom to clean an attic, while 
the rest of the family is chilling downstairs.

- There is no single code base, everything is scattered. Scary.
- There is no product roadmap, and no worthy possible tasks.
- Bug fixes hardly warrant a GSoC task.

> Mouse-driven GUI is always at the top of the list for new DOS
> developers, right next to "64-bit FreeDOS" and "Raspberry Pi FreeDOS."
> You know, all the things DOS wasn't made to do. :-P

Why not make a fully modern operating system with DOS conventions, and keep the 
old DOS interface as a compatibility mode, and still a separate download for 
those who wish it? Mega65 does something similar. DOS stopped being a moving 
target 30 years ago.

Even the idea “modern OS with DOS conventions” is a very challenging idea  
generator. Just target QEMU and/or a specific board that is available for a 
couple of bucks, and let people play with it. Even the hardware support may 
pick up later on (e. g. SerenityOS). Then there will be lots of ideas and 
opportunities for students to play around.

Best regards,
Emir (ఽ఺఍)

** E-mail needs to stay simple
** Use plain text e-mail



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Jim Hall]

> > What core programs or components should we put into the application -
> > if we apply and can get accepted?

On Sun, Jan 22, 2023 at 12:11 PM Robert Riebisch  wrote:
> A mouse-driven GUI...
>
> SCNR :-D

Funny! :-)

Mouse-driven GUI is always at the top of the list for new DOS
developers, right next to "64-bit FreeDOS" and "Raspberry Pi FreeDOS."
You know, all the things DOS wasn't made to do. :-P


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Ralf Quint]

On 1/22/2023 10:28 AM, Robert Riebisch wrote:

Hi Ralf,


So let's discuss:

What core programs or components should we put into the application -
if we apply and can get accepted?

A mouse-driven GUI...

SCNR :-D


No, PLEASE, NO! 

Was just kidding...


You DID notice the smiley at the end, didn't you? ;-)




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Robert Riebisch]

Hi Ralf,

>>> So let's discuss:
>>>
>>> What core programs or components should we put into the application -
>>> if we apply and can get accepted?
>> A mouse-driven GUI...
>>
>> SCNR :-D
>>
> No, PLEASE, NO! 

Was just kidding...

Cheers,
Robert
-- 
BTTR Software   https://www.bttr-software.de/
DOS ain't dead  https://www.bttr-software.de/forum/

___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Ralf Quint]

On 1/22/2023 10:11 AM, Robert Riebisch wrote:

Hi Jim,


So let's discuss:

What core programs or components should we put into the application -
if we apply and can get accepted?

A mouse-driven GUI...

SCNR :-D


No, PLEASE, NO! 


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Robert Riebisch]

Hi Jim,

> So let's discuss:
> 
> What core programs or components should we put into the application -
> if we apply and can get accepted?

A mouse-driven GUI...

SCNR :-D

Cheers,
Robert
-- 
BTTR Software   https://www.bttr-software.de/
DOS ain't dead  https://www.bttr-software.de/forum/


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Michael Brutman]

Chris DiBona, the Senior Director of Open Source at Google was caught in
the massive wave of lay-offs that Google executed this past Friday.  His
group is responsible for the Summer of Code.  The departure of specific
people might not have an impact, but I would still try to be realistic
about expectations.

The Haiku calendar app is definitely niche, so maybe there is hope ...
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Bernd Boeckmann via Freedos-devel]

> Am 22.01.2023 um 03:46 schrieb Michael Brutman :
> 
> I don't think you are going to get too far with an application ...  I hate to 
> be so blunt here, but it takes more than just being open source.  It has to 
> be a project with significant impact, and I think that FreeDOS is way too 
> niche to be considered.

In that point I tend to disagree. It seems that even a calendar application for 
the not so mainstream Haiku operating system was on the list, see

https://summerofcode.withgoogle.com/programs/2022/projects/Aw6dks92

https://www.haiku-os.org/blog/harshitsharma/2022-09-12_gsoc_2022_final_report_improving_the_calendar_application/

Because of the relevance of FreeDOS for supporting legacy systems I think the 
chances are anything but zero, and in my opinion it is a great idea!


Greetings, Bernd



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code?

[Michael Brutman]

I don't think you are going to get too far with an application ...  I hate
to be so blunt here, but it takes more than just being open source.  It has
to be a project with significant impact, and I think that FreeDOS is way
too niche to be considered.

You're going to be competing against many other open source projects that
probably can demonstrate incredible levels of positive impact to larger
groups of people.  When weighed against those projects, FreeDOS will not
make the cut.


-Mike
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Google Summer of Code

[Jim Hall]

On Mon, Sep 5, 2022, 1:29 PM Wilhelm Spiegl  wrote:

> Hi Paul,
> did you or Jim or somebody else think about Google summer of code for
> FreeDOS, e.g. 2023 as this summer is almost over? Just a (bad) idea.
>
> https://summerofcode.withgoogle.com/
>


GSoC is a good idea, we should think about doing this next summer. There's
an application process for open source projects to participate, but it
looks like Google (not the open source project) is the one that pays
interns, so that's good for us.

We'd need to line up a mentor or mentors for the intern to work with.


Jim
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel