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] UEFI, virtual BIOS and virtual hardware - was: Google Summer of Code?

[Louis Santillan]

Over the last couple years, DOSBox and DOSBoxPure in RetroPie and RetroArch
have become quite popular.

https://m.youtube.com/watch?v=LRy8brZ7DVc
https://m.youtube.com/watch?v=-mD2DnMVoLE

Consider standardizing on that.  RPis will have access via RetroPie.
There’s a version of DOSBox in the various Android stores as well.  Windows
support, Mac OS support.  For “real hardware” PCs including modern UEFI,
there’s RetroArch’s Lakka Linux distribution.  Even a lot of support for
less common SBCs.

https://www.lakka.tv/


On Mon, Jan 23, 2023 at 2:56 PM Steve Nickolas  wrote:

> On Mon, 23 Jan 2023, E. Auer wrote:
>
> 
>
> > Depending on how thin the glue and VM layer will be, you will be able
> > to run fewer or more DOS apps with it. You can run some DOS apps in
> > CTTY serial consoles if they only use int 21 for user I/O. There are
> > support modes for simple DOS apps in some boot managers which only
> > implement a few most popular bits of the DOS API to run apps directly
> > from the boot manager without an actual DOS. So why not use for example
> > real mode DOS apps without sound, with whatever is left in terms of
> > hardware text mode or maybe VGA as an already entertaining intermediate
> > milestone and keep more VGA, VESA, PC speaker, mouse, protected mode
> > apps etc. pp. for later? The "easy" solution will still be running a
> > DOS-friendly VM inside Linux or other host OS. But not the exciting
> > solution regarding technological challenge and "abstraction thinness".
> >
> > People have written hypervisors to hide malware. Porting an open BIOS
> > and some VM ingredients into a CSM and an open source "VMware ESXi"
> > competitor which runs DOS better than the commercial product does?
> > In other words, a Xen for DOS? To stay in the Xen terminology, would
> > one want a paravirtualized DOS for that? Or would one put some light
> > weight "BIOS setup" type menu into dom0 and run DOS only as client?
>
> This is kind-of what I was trying to hint at - a lightweight operating
> system that just manages the hardware and (if necessary) provides
> emulation for 16-bit apps.  I feel like even a stripped-down Linux kernel
> is extreme overkill since multitasking/multiuser isn't even useful for
> that purpose.
>
> But in this day and age where the solution to everything is "throw a
> 'Duino at it" or "throw a RasPi at it", I think too many people have lost
> the concept of simple, lightweight, minimalist software.  And that's why
> you have all the kids trying to turn FreeDOS into Linux, and Linux into
> Windows.
>
> The idea is this: provide a "volume manager"; a way to use the installed
> hardware to emulate VGA/SVGA, SB16, and the basic equipment used on DOS
> machines; and hooks to MS-DOS/FreeDOS to support stuff you're likely to
> have on a modern machine that wouldn't be supported.  And since it's quite
> possible that in the future 8086 and 80286 mode will finally get the axe,
> it might be necessary to move them to actual emulation (maintaining, if
> possible, virtualization for 32-bit software).
>
> I'm also kind-of thinking MacOS 7.x, that had the 68030 emulator to run
> parts of the OS on PowerPC systems...
>
> -uso.
>
>
> ___
> 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] FreeDOS / Jim on TheRegister

[Jim Hall]

On Mon, Jan 23, 2023 at 5:50 PM Aitor Santamaría  wrote:
>
> Hello,
>
> Founder of FreeDOS recounts the story so far, and the future • The Register

Thanks to Liam for the interview. We discussed the history of FreeDOS,
and some of the directions we've been talking about here, off and on.

I think we could have gone on for much longer than we did. There's a
lot of cool stuff about FreeDOS to talk about. We just ran out of
time. I didn't get to say enough about the community - that's why
FreeDOS is still around, because it's a community thing.


Jim


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

[Freedos-devel] FreeDOS / Jim on TheRegister

[Aitor Santamaría]

Hello,

Founder of FreeDOS recounts the story so far, and the future • The Register


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

Re: [Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Google Summer of Code?

[Steve Nickolas]

On Mon, 23 Jan 2023, E. Auer wrote:




Depending on how thin the glue and VM layer will be, you will be able
to run fewer or more DOS apps with it. You can run some DOS apps in
CTTY serial consoles if they only use int 21 for user I/O. There are
support modes for simple DOS apps in some boot managers which only
implement a few most popular bits of the DOS API to run apps directly
from the boot manager without an actual DOS. So why not use for example
real mode DOS apps without sound, with whatever is left in terms of
hardware text mode or maybe VGA as an already entertaining intermediate
milestone and keep more VGA, VESA, PC speaker, mouse, protected mode
apps etc. pp. for later? The "easy" solution will still be running a
DOS-friendly VM inside Linux or other host OS. But not the exciting
solution regarding technological challenge and "abstraction thinness".

People have written hypervisors to hide malware. Porting an open BIOS
and some VM ingredients into a CSM and an open source "VMware ESXi"
competitor which runs DOS better than the commercial product does?
In other words, a Xen for DOS? To stay in the Xen terminology, would
one want a paravirtualized DOS for that? Or would one put some light
weight "BIOS setup" type menu into dom0 and run DOS only as client?


This is kind-of what I was trying to hint at - a lightweight operating 
system that just manages the hardware and (if necessary) provides 
emulation for 16-bit apps.  I feel like even a stripped-down Linux kernel 
is extreme overkill since multitasking/multiuser isn't even useful for 
that purpose.


But in this day and age where the solution to everything is "throw a 
'Duino at it" or "throw a RasPi at it", I think too many people have lost 
the concept of simple, lightweight, minimalist software.  And that's why 
you have all the kids trying to turn FreeDOS into Linux, and Linux into 
Windows.


The idea is this: provide a "volume manager"; a way to use the installed 
hardware to emulate VGA/SVGA, SB16, and the basic equipment used on DOS 
machines; and hooks to MS-DOS/FreeDOS to support stuff you're likely to 
have on a modern machine that wouldn't be supported.  And since it's quite 
possible that in the future 8086 and 80286 mode will finally get the axe, 
it might be necessary to move them to actual emulation (maintaining, if 
possible, virtualization for 32-bit software).


I'm also kind-of thinking MacOS 7.x, that had the 68030 emulator to run 
parts of the OS on PowerPC systems...


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

[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

[Freedos-devel] UEFI, virtual BIOS and virtual hardware - was: Google Summer of Code?

[E. Auer]

Hi Bret,

thanks for the great summary!


For awhile, the UEFI manufacturers provided a CSM (Compatibility
Support Module) as the "translation layer" so you didn't need a VM.
But they've even stopped doing that nowadays.  So, we'll either need
to come up with a "generic CSM" that doesn't need a VM but still
provides the needed level of hardware support both now and in the
future, or we'll need to do some kind of "thin VM" as Jerome is
suggesting.  I think the second option has a better chance of
long-term viability even though I would prefer the first.


My impression based on earlier discussions and/or BTTR forum threads
would be that there are "open source BIOS" initiatives which could be
a starting point for a large point of a "generic CSM" (BIOS module to
load on UEFI systems before booting DOS, with some magic glue needed)
at least for actually more aspects of the BIOS than normal DOS and DOS
apps will require :-) I can imagine that the dosemu2 people also have
interesting expert thoughts about that and those magic glue problems
involved.

Depending on how thin the glue and VM layer will be, you will be able
to run fewer or more DOS apps with it. You can run some DOS apps in
CTTY serial consoles if they only use int 21 for user I/O. There are
support modes for simple DOS apps in some boot managers which only
implement a few most popular bits of the DOS API to run apps directly
from the boot manager without an actual DOS. So why not use for example
real mode DOS apps without sound, with whatever is left in terms of
hardware text mode or maybe VGA as an already entertaining intermediate
milestone and keep more VGA, VESA, PC speaker, mouse, protected mode
apps etc. pp. for later? The "easy" solution will still be running a
DOS-friendly VM inside Linux or other host OS. But not the exciting
solution regarding technological challenge and "abstraction thinness".

People have written hypervisors to hide malware. Porting an open BIOS
and some VM ingredients into a CSM and an open source "VMware ESXi"
competitor which runs DOS better than the commercial product does?
In other words, a Xen for DOS? To stay in the Xen terminology, would
one want a paravirtualized DOS for that? Or would one put some light
weight "BIOS setup" type menu into dom0 and run DOS only as client?
Wikipedia mentions Alpine Linux offering a rather small Linux dom0.

https://en.wikipedia.org/wiki/Proxmox_Virtual_Environment and KVM may
also be an interesting combination to look at? Checking for others in
https://en.wikipedia.org/wiki/Comparison_of_platform_virtualization_software
my impression is that those Hypervisors which run on bare metal somehow
tend to be either Linux specific or commercial and proprietary things?

Regards, Eric



___
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