Re: [Freedos-devel] What are the blocking bugs/issues for FreeDOS 1.3?

[Bret Johnson]

I saw Wilhelm's earlier comment and started thinking about some of its 
implications:  i) NLS support: Is there anybody who can tell me if all DOS 
commands support [J(a)|Nein] or [O(ui)|N(on)] etc. instead of [Y(es)|N(o)]? If 
not, they should do it. As a translator you never know what to do.  Supporting 
multiple languages brings up all kinds of technical issues.  E.g., there are at 
least three different ways to approach this: compile all the languages into one 
executable file (makes for a very large file and also requires recompilation if 
a new language is added), compile different executables for each language 
(creates lots of different executable files where each needs a separate name), 
or have a "base" executable with separate "adjunct" files for each language 
(probably the most efficient option in terms of total size).
 A major issue is that interactive items (like Yes/No or Abort/Retry/Fail) 
require two-way interaction.  That is, in addition to displaying different 
things on the screen for the different languages, you also have different input 
keys that can respond to the different options (e.g., Y/N for English and J/N 
for German).  That gets really ugly to program and from a design perspective it 
becomes an issue as to where the store the input key data.  That is, 
particularly if you have a common "base" program with separate language files, 
where does the data for the correct input keys (which vary by language) get 
stored -- in the base program or in the language file?  Does the base program 
really even need to know what language is being supported or can the base 
program be totally independent of language and ALL the language data (both 
input and output information) is contained in the language files?
  This gets further complicated if you support languages that aren't based on a 
Latin alphabet (Cyrillic, Arabic, CJK, Greek, and Hebrew come to mind 
immediately) where the Code Page comes into play as well (and the ASCII codes 
for the input key data can vary depending on the current Code Page).
  I'm really wondering if anybody has really thought this all the way through 
and has some sort of flexible structure figured out.  I've considered adding 
language support to some of my programs (if I could get someone to do the 
translations), but just designing a support structure to handle all the 
possibilities is pretty daunting.
  I realize this doesn't have a direct relationship to FreeDOS 1.3, but it got 
me to thinking about the complications of language support in general.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] video FreeDOS running Windows 3.1

[Eric Auer]

Hi Jeremy, others,

> Kernel patches - http://server2.fdos.org/tests/kernel-win3-patch.diff
> rest of sources (kernel, FreeCOM, format, fdisk, sys, share, edit) -
> https://github.com/fdos

I have been browsing those patches a bit. So I can share some insights
about them, also implying many questions. Maybe Jeremy can explain the
areas which looked complicated or confusing to me. Maybe the confusing
areas even include some which actually could use code improvements :-)

Sorry about the length of the "review" below.

>  hdr/portab.h  |   7 +
>  kernel/entry.asm  | 186 -
>  kernel/init-mod.h |   4 +-
>  kernel/int2f.asm  |  51 ++-
>  kernel/inthndlr.c | 340 +-
>  kernel/kernel.asm |  37 -
>  kernel/main.c |  19 ++-
>  7 files changed, 623 insertions(+), 21 deletions(-)

portab.h just introduces loword and hiword access macros

entry.asm: there is a new int 13 handler, but the style worries me.
It does CLI STC, then calls the original handler while forcing DS
to be the kernel one, then increments SP twice, then returns with
STI via RETF 2. Why all those things? Changing the interrupt flag,
carry flag and DS all seem to be a bad idea and SP should probably
not be incremented like that either, it gets unaligned for a moment.

The actual action "if carry set and AH is 6 on return" even is
commented out right now and the 8086-compatible method of pushing
the value 13h for that looks convoluted.

There also is some intWrapCall helper which uses a lot of stack.

The next new thing in entry.asm is a new step for the int 19 handler
which uses intWrapCall to call int 19 instead of just doing "int 19",
but I do not see what the advantage of that is supposed to be.

Interestingly, int21_user only calls dos_crit_sect if NOT compiled
with Windows 3.1 386enh support? If compiled WITH that, there will
instead be an int 2a.8001 call (preserving AX) before byte InDOS is
incremented. Also, dos_crit_sect is only called at int21_3 if NOT
compiled with Windows support, while it is called after decrementing
InDOS at int21_exit instead if compiled WITH Windows support?

Note that there is NO call to int 21.8101 (leave critical section) at
that point (it is commented out via "if 0") and that dos_crit_sect
is what is called (copies AX to a local variable, calls int 2a.82
with preserved AX) which leaves all critical sections 0-7, instead
of just a specific one as int 2a.810x would do after int 2a.800x
has been called to enter it?

What is the "skip to int21_3 if ah is 6" thing about, which has a
comment "testing, this function call crashes" next to it?

init-mod.h: Adds the int13_handler and makes the lol FAR *const LoL,
adding const to the properties of the list of lists pointer.

int2f.asm: Adds IntDosCal style functions 13h and 46h and
clears BX for function 4a33h for some "undocumented" reason?

If Win 3.1 support is compiled in, some non-reentrant switch to a
local mux2F_stk_top-30 will be triggered, copying 13 words to it,
while preparing for IntDosCal style int 2f functions, of course
copying everything back to the user stack later. Why the effort?

inthndlr.c: Includes a whole new win.h (as well as debug.h) but
win.h itself does not seem to be part of the Win 3.1 compatibility
patch? I seem to be missing something here? It also accesses BIOS
and user int 13 and int 19 vectors.

The updated int2F_12_handler() now has ah=13h "disk interrupt hook"
functionality as described in RBIL, which is used by Windows to mess
with disk I/O in WDCTRL.386 which insists on this to at least return
a changed DS when invoked. It also implements int 2f.1600 / 2f.160a
(both NOP), int 2f.1603 (get instance data, dummy because 1607.bx=15
is preferred), int 2f.1605 (Win startup broadcast, returns some data
structure, of course does not return optional vm86 on/off callback),
2f.1606 (Win exit broadcast, just logged at the moment)

int 2f.1607 is the large VxD API, BX selects which VxD to work with:
Only bx 15h supported, DOSMGR: CX 0 returns a flag, the DOS driver
data segment (segment of nul_dev) and a patch table, CX 1 activates
and CX 2 optionally deactivates patches, CX 3 returns DOS sizes of
DOS data structures, CX 4 tells about instance data structures etc.:

FreeDOS just reports it would have patched everything as requested
for critical section support, to keep Win3 from trying to patch it.
This involves features such as int 2a.8x0x calls, machine ID tracking,
limiting atomic I/O size (split up to multitask better) and notifying
Windows if "halt on stack error" or for "floppy drive DJ messages".

For function 3, only the CDS size is counted: FreeDOS pretends that
SFT, device list and SDA would all be zero size. Sounds dangerous!
Why is the implementation like that? Would Windows only care about
the CDS size? What if multiple DOS boxes are opened in Windows 3?
Our function 4 suggests that FreeDOS tries to avoid function 3?

In function 4, DOS could tell which 

Re: [Freedos-devel] What are the blocking bugs/issues for FreeDOS 1.3?

[Eric Auer]

Hi Tom,

to quote a 2018 FAT16 speed test example by Jack, copying a
mix of files and directories of different sizes disk to disk:
Plain FreeDOS 65s
With LBACACHE 61s adds a small cache
With UIDE 51s adds UDMA and larger cache
With UHDD 47s all the above plus read-ahead
With XHDD 43s all the above plus I/O transfer overlap

Plain MS DOS 6.22 39s
With UIDE 30s adds UDMA and large cache
With UHDD 27.5s all the above plus read-ahead
With XHDD 26.5s all the above plus overlap

By now, the drivers have evolved further, but you can
see a clear speed difference both with and without them.

Interestingly, even FreeDOS XCOPY takes 10 % longer
than MS XCOPY (both on MS DOS), probably because we
use unaligned copy_file() buffers and call getdfree()
too often. Could work with incremental estimates and
only call getdfree() when in doubt. Also: chmod r/w?
Loading NANSI at least improves screen I/O speed ;-)

In a more recent 635 MB CF to CF copy test by Jack,
FreeDOS XCOPY with MS DOS kernel and UHDD took 26
seconds, versus 44 seconds in FreeDOS. While CF is
probably a low IOPS medium, there is some room for
improvement for FreeDOS, even with harddisks or SSD.

Regards, Eric




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

Re: [Freedos-devel] What are the blocking bugs/issues for FreeDOS 1.3?

[Jerome Shidel]

Hi Eric,

One more thing...

> On Jul 27, 2021, at 10:59 AM, Eric Auer  wrote:
> [..]
> There seems to be a bug in the overview HTML file, which says
> the floppy edition images are 12 MB or use 120m or 144m media:
> 
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/previews/1.3-rc4/report.html

Then... In the Floppy-Only Edition section:
 
It says 720k, 120m and 144m. These are just based on settings and file names 
which don’t have dots 
in them. But if it bothers you, I can update it to modify what it displays to 
720k, 1.2m and 1.44m. However,
it report won’t change until release build (RC5 or Final). 

:-)

Jerome




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

Re: [Freedos-devel] What are the blocking bugs/issues for FreeDOS 1.3?

[Jerome Shidel]

Hi Eric,

> On Jul 27, 2021, at 10:59 AM, Eric Auer  wrote:
> [..]
> It also is important for me that old bugs in the autoexec and
> config files get fixed. Given that some of those are created
> dynamically, this is a task for the installer experts. See my
> old mailing list thread about the topic earlier this year.

Bugs in the autoexec and config?

Do you mean the changes you want to increase performance?

Although improvements could be made, it is not a bug just because you want it 
changed.

> [..]
> There seems to be a bug in the overview HTML file, which says
> the floppy edition images are 12 MB or use 120m or 144m media:
> 
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/previews/1.3-rc4/report.html
>  
> 

Not a bug. The number 12mb you are referring to is under the CD-BOOT image 
section.

The LiveCD has the Alternate Floppy Only Edition in non-diskette format. It is 
the Easter Egg install method we mentioned a while back. That image is a 12mb 
and is a bootable HD image. As long as the BIOS can boot it, it also provides a 
means to boot and install FreeDOS from the CD without ANY dos level support for 
the CD/DVD drive. 

> I would wish the LegacyCD to include all packages of the LiveCD.

Mostly they do with exception. There are some very popular packages on the 
LiveCD that don’t get installed normally. I only provided them on the LiveCD 
because it could be very painful to try and install them into the Live 
Environment if the user cannot switch or access the BonusCD. 

Remove the extras from the LiveCD, add them to the Legacy CD? Lots of options. 

> [..]
> Some packages are likely to be OUTDATED. Checking this would be a
> task which could be distributed over a few people who want to help
> without having to code: They can go over the LSM and compare the
> packaged version number to the one of upstream app websites, or
> trivially skip packages which are unmaintained upstream anyways.

That’s a great idea. 

At present there is mostly a team of one that does that now… Sometimes, when 
time permits 
and fells like doing it. :-)

It often helps a lot that Jim mirrors many updates. But, those are not “ready 
to rock” packages.

Did you know there is an updated version of LABEL available that supports NLS? 
It has be out
for a while. But, requires being compiled and packaged. I’ll get to it 
eventually. 

When it comes to updating packages from source only releases, they often get 
put off for a long 
time. It can take minutes to many hours to get a build environment working for 
just one such 
program. Spread that over multiple packages that need built and nothing else 
gets done.

> [..]
> I suggest to have some more compilers etc. on the normal install
> images, NOT moved away to the BonusCD: FASM, FBC with help, FPC,
> INSIGHT, JWASM, NASM, UPX. Possibly also OW and the I16 compilers.

Based on the Jim’s recent survey, that may be a very good idea. 

> It is unfortunate that TPPATCH (runtime error 200) is out, maybe
> some alternatives with better license exist, also for TC apps?

There might be. But, I’ve looked a little for one but didn’t see any. 
However, if the source is available for the program, you can swap
out the uses “CRT” for my “QCrt” unit. It’s compatible, does more
and is much much faster.

> Not sure why FDINST and FDISRC are separate packages?

FDINST is an “unreal” package. FDINST is the 8086 compatible 
(without networking) alternative to FDNPKG (req 386). It has it’s own 
pseudo-package to make it easier for the Floppy Only Edition
to install only software supported by the hardware (which can be 
overriden to install everything). Anyhow, that is why it is listed 
as only on the Floppy Only Edition for 8088-80286 machines.

FDISRC is the raw sources for the primary installer. This is 
not the same as what is on the install media. A large amount
of processing is done to the raw sources in order to get 
a working installer. Things like keyboard support and language
translations undergo analysis and conversion by the RBE into
stuff that can be used by the installer.  It’s not much use to
anyone in it’s raw form. So, never gets installed.  But, is provided
to maintain compatibility with open source licenses. Although, it is 
available on GitHub.

On a side note, the RBE is awesome and very easy to setup and 
use to build custom releases of FreeDOS. Want a custom EricDOS,
no problem. Take a handful of minutes to change a could settings,
run build, come back a little while later and there it is. At present, 
it could be a little easier to deviate from the current package lists.
And eventually, I’ll add direct support to do that. But, even now
it can automatically include stuff we don’t even provide and it
is fairly trivial to change the package lists it uses. 

Almost anyone can build a custom release, with almost no effort at 
all. Just need to 

Re: [Freedos-devel] What are the blocking bugs/issues for FreeDOS 1.3?

[tom ehlert]

Hi Eric,

> It is important for me that both the installer and the installed
> FreeDOS use UHDD when possible, to improve performance, given the
> lack of I/O speed of our kernel itself, in particular for FAT32.

could you please detail how you measured 'the lack of I/O speed of our
kernel', and compared this to what? for what kind of operations?

what are your expectation of performance?
in particular for FAT32 the performnce is MUCH better then MSDOS;)

>LFN are an interesting problem, FreeCOM itself only uses them on
>request (DIR /LFN) as far as I remember.

the 'new' FreeCOM has LFN support just everywhere. you should have
tested it a while ago.


>   Most apps probably do
>not really care, so FreeCOM could be "empowered" to automatically
>translate long names to short names for all apps which are on a
>list of LFN-unaware apps?
already done. it's called SFN and is part of the kernel since 1995.




Tom




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

Re: [Freedos-devel] What are the blocking bugs/issues for FreeDOS 1.3?

[Eric Auer]

Hi everybody,

I also agree that there should be a next release candidate
first, not immediately a FreeDOS 1.3 release.

Even when RC5 is perfect, nobody would stop us from simply
bumping the version number for release. And when it is not
perfect, things can be improved before the actual release.

I do NOT think that ALL open issues should be fixed for a
simple FreeDOS 1.3 release, that would be more something
for a FreeDOS 2.0 release ;-)

Things I want to be addressed for the next release candidate
are in particular the disk drivers: Is my theory correct that
the disk caches (lbacache or uhdd) could have a problem with
the ELTORITO driver? Can we make more protected games work by
tuning the UDVD2 driver or maybe add a cheat to the CDRCACHE?

It is important for me that both the installer and the installed
FreeDOS use UHDD when possible, to improve performance, given the
lack of I/O speed of our kernel itself, in particular for FAT32.

For ELTORITO boot mode, CDRCACHE would also have to be used,
because UHDD cannot cache other CD/DVD drivers than UDVD2.

It also is important for me that old bugs in the autoexec and
config files get fixed. Given that some of those are created
dynamically, this is a task for the installer experts. See my
old mailing list thread about the topic earlier this year.

In vaguely related news: Please make the LiteUSB image 32 MB,
so there is enough free space to work on the USB stick with it.

There seems to be a bug in the overview HTML file, which says
the floppy edition images are 12 MB or use 120m or 144m media:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.3/previews/1.3-rc4/report.html

I would wish the LegacyCD to include all packages of the LiveCD.

Can we tame FDISK to no longer nuke existing MBR without asking
triggered by the mere absence of the 55 aa magic? Can FDISK have
the MBR sub-menu enabled for interactive mode and can all three
MBR code options announced in the docs actually be made accessible
for scripted command line style installation? Can it have a mode
to check for existing MBR code, using Jerome's new detection tool
as reference implementation? Or should we just switch to XFDISK?

There also are some ideas for FDAPM (parse larger ACPI blocks),
CTMOUSE (become 8086 compatible), NGE NIBBLES (improve docs for
my update, requested by Jim), CDROM2 (add STOP and UPC commands),
CDRCACHE (remove messages about raw access), LBACACHE (see above)
and probably others.

Some of the above would require help from people who can do very
specific tests (e.g. with eltorito boot versus caches, protected
games versus CD/DVD, or CPU compatibility analysis of ctmouse to
make sure no non-8086 code gets overlooked). Other items would be
mostly documentation-specific (cleaning up my NGE NIBBLES update).

I agree that AMB is a nice addition but not necessarily a full
replacement for HTMLHELP, so both should stay available for now,
given that HTML is a more widespread documentation format.

Note sure which commands lack FAT32 support yet? DEFRAG comes
to mind, maybe CHKDSK for those who do not want to use DOSFSCK?
Could you make a list, Willi?

LFN are an interesting problem, FreeCOM itself only uses them on
request (DIR /LFN) as far as I remember. Most apps probably do
not really care, so FreeCOM could be "empowered" to automatically
translate long names to short names for all apps which are on a
list of LFN-unaware apps? Not something for FreeDOS 1.3 though.

For FreeCOM and kernel, I would want the CHANGELOG (!) to reflect
the current state of affairs in the version which gets included
into a real FreeDOS 1.3 release. For a release candidate, it is
okay to have some "undocumented improvements", but actual releases
should really have their changelog documentation in up to date :-)

Weird that documentation exists about BACKUP and RESTORE, but no
actual tool? Could be either a planned pair of tools or one which
got lost in the last decades? People can use ZIP as workaround,
but having documentation about non-existing apps is confusing.

I expect that by far not all DOS apps support translated Y/N etc.,
but I bet that somebody already has a list which ones do or do not?

Some packages are likely to be OUTDATED. Checking this would be a
task which could be distributed over a few people who want to help
without having to code: They can go over the LSM and compare the
packaged version number to the one of upstream app websites, or
trivially skip packages which are unmaintained upstream anyways.

If I remember correctly, LHA and UNRAR have unresolved license
issues? Same for AHCICD and MPXPLAY, alas. I have tried to ask
the maintainer of the latter, but got no reaction so far. Maybe
somebody here has better connections to him?

I suggest to have some more compilers etc. on the normal install
images, NOT moved away to the BonusCD: FASM, FBC with help, FPC,
INSIGHT, JWASM, NASM, UPX. Possibly also OW and the I16 compilers.

It is unfortunate that TPPATCH 

Re: [Freedos-devel] What are the blocking bugs/issues for FreeDOS 1.3?

[Wilhelm Spiegl]

Hi Thraex,
I agree with you. A RC5 would also be helpful for me to see if everything works 
correct.
With some of NLS files at Github I have absolutely no idea why it should make 
sense to
translate them at all. So I will not translate them for the moment.
 
From my side there is a more basic problem:
As I see it as a user, FreeDOS is finished for estimated 60 percent. I will try 
to explain it below.
But I think it should work stable enough for a new RC5 - and maybe a 1.3 when 
this RC5 is out.
 
Okay, lets start with the question why it is finished for 60 %:
 

As I am not sure if I will have time for the next meeting, here some ideas.
I do not say that it should already be implemented in the next version, but I 
think it should be done some day
to come to an end with a complete FreeDOS. I know it is problematic to find 
programmers, but when the following
things are done step by step it will work very fine some day.
a) external commands: Some of them have a text in the readme file: "still to 
do", "known bugs" "roadmap" etc.
   These commands should be checked and all these things fixed (if necessary, 
otherwise text should be removed)
b) a lot of (external) commands support no NLS. This should be added to get a 
unique system. I know that this
   is a lot of work, but it makes sense in my eyes.
c) fixing the bugs reported on the FD Bug Tracker at Sourceforge - independent 
which priority is actually set.
d) (html)help still does not work correct; AMB is a nice feature but it does 
not directly work with htm-files,
   so it may become a problem some day. And there is a basic update available 
on Jeromes github site.
e) scandisk 0.5 - a fine tool, but it never worked. Only the GUI exists. Would 
be nice to have it some day.
f) support for FAT32 and lfn for all commands,
g) with some compilers / whatever it is VERY VERY hard to write an NLS file. 
Especial when there are variables
   within the text as each language has a different grammatic. You have to look 
three times what is text and
   what is no text to translate. Would it be possible to avoid such compilers?
h) at https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/backup/ 
there are two htm files that
   describe backup/restore. One of them is written by Ralf Quint, a member of 
the FD group. (hi Ralf,
   Warsteiner is not the best german beer).
   Till today I only saw this htm file but no binary. Is this binary available? 
Can it be added?
i) NLS support: Is there anybody who can tell me if all DOS commands support 
[J(a)|Nein] or [O(ui)|N(on)] etc. instead
   of [Y(es)|N(o)]? If not, they should do it. As a translator you never know 
what to do.
 
This is only a collection of ideas that shall help to get FreeDOS to a "final" 
version.
 
 
Willi

@ Thomas Muller: Is this text format ok?
 
 

Sent: Tuesday, July 27, 2021 at 12:49 PM
From: "thraex" 
To: freedos-devel@lists.sourceforge.net
Subject: Re: [Freedos-devel] What are the blocking bugs/issues for FreeDOS 1.3?

On 26.07.2021 01:29, Jim Hall wrote:

> And: With the updates we have, are we ready to release this as
> "FreeDOS 1.3" or do we need a "FreeDOS 1.4 RC5"?

As a translator and somewhat a tester, IMHO a RC5 would be necessary.
For example, when one chooses the French or Turkish (and possibly other)
keyboard layouts on the installer, after the installation this is not
taken into account (bug 282 & bug 306).

FreeCOM wasn't using some of the translations in RC4, so there was no
easy way to check if they were OK (see
).

I stupidly left French translations of diskcopy, fdnpkg, md5sum and mem
in UTF-8 (no idea how I managed this, sorry) -- this will be fixed when
Jerome has time to take care of
.

Fritz Mueller also brought to my attention some mistakes in Blocek
translations (keyboard shortcut & charset issues) that I need to fix
(and Blocek 1.62 would need to be packaged to replace 1.4 if Laaca
doesn't finish and release 1.7 in time for FreeDOS 1.3).

Obviously none of these are showstoppers but as compiling this stuff is
beyond my abilities, I'd love to be able to check it with a new RC and
make final adjustments if necessary to avoid giving a bad overall
impression to newbies like me.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel[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] What are the blocking bugs/issues for FreeDOS 1.3?

[thraex]

On 26.07.2021 01:29, Jim Hall wrote:

> And: With the updates we have, are we ready to release this as
> "FreeDOS 1.3" or do we need a "FreeDOS 1.4 RC5"?

As a translator and somewhat a tester, IMHO a RC5 would be necessary.
For example, when one chooses the French or Turkish (and possibly other)
keyboard layouts on the installer, after the installation this is not
taken into account (bug 282 & bug 306).

FreeCOM wasn't using some of the translations in RC4, so there was no
easy way to check if they were OK (see
).

I stupidly left French translations of diskcopy, fdnpkg, md5sum and mem
in UTF-8 (no idea how I managed this, sorry) -- this will be fixed when
Jerome has time to take care of
.

Fritz Mueller also brought to my attention some mistakes in Blocek
translations (keyboard shortcut & charset issues) that I need to fix
(and Blocek 1.62 would need to be packaged to replace 1.4 if Laaca
doesn't finish and release 1.7 in time for FreeDOS 1.3).

Obviously none of these are showstoppers but as compiling this stuff is
beyond my abilities, I'd love to be able to check it with a new RC and
make final adjustments if necessary to avoid giving a bad overall
impression to newbies like me.


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