Hi!
SvarCOM has a completely different code base than FreeCOM and is under a
different license (MIT). It implements a bare minimum MS COMMAND.COM compatible
shell (not sure if it is 100% compatible, but I am not aware of anything that
is missing). It does not support things like extended comman
Hi,
Can someone briefly describe the differences of current COMMAND.COM and
that of svarDOS? (if other than bug fixes).
Aitor
On Mon, 16 Dec 2024 at 21:52, Eric Auer via Freedos-devel <
freedos-devel@lists.sourceforge.net> wrote:
>
> Hi!
>
> > It's probably time to kill (or at least build and
That'd be a great idea.
The best guarantee to have it running on any modern PC, even more than BIOS
implementations over UEFI (although it'd be less compatible, in the sense
that less similar to a clean DOS environment).
Aitor
On Mon, 16 Dec 2024 at 16:05, Liam Proven via Freedos-devel <
freedos
On Fri, 20 Dec 2024, Liam Proven via Freedos-devel wrote:
On Tue, 17 Dec 2024 at 21:35, Steve Nickolas via Freedos-devel
wrote:
IBM. They owned the copyright jointly from version 3.1 onward (note that
they specifically said they had to get the OK from IBM to release the 4.0
sources).
IBM w
On Tue, 17 Dec 2024 at 21:35, Steve Nickolas via Freedos-devel
wrote:
> IBM. They owned the copyright jointly from version 3.1 onward (note that
> they specifically said they had to get the OK from IBM to release the 4.0
> sources).
IBM was the first ever licensee of MS-DOS. It was built for IB
Wine runs 16-bit Windows programs on 64-bit Windows by the use of 16-bit
protected mode segments through modifying the Local Descriptor Table. The
64-bit Windows port of WineVDM (OTVDM) has to use a CPU emulator because
processes can only modify their LDT on 32-bit Windows (where you can just
use n
On 12/16/2024 9:22 AM, Liam Proven via Freedos-devel wrote:
On Sun, 15 Dec 2024 at 07:25, Steve Nickolas via Freedos-devel
wrote:
I mean, something like a free Windows 3.0 or a free Desqview/X would be
nice, but eh.
It would indeed.
The thing is, it more or less exists: it's PC GEOS.
https:
On Tue, 17 Dec 2024, Liam Proven via Freedos-devel wrote:
On Mon, 16 Dec 2024 at 19:23, Steve Nickolas via Freedos-devel
wrote:
Part of the problem there was MS didn't have full copyright.
[[citation needed]]
Who else?
IBM. They owned the copyright jointly from version 3.1 onward (note
On Mon, 16 Dec 2024 at 19:23, Steve Nickolas via Freedos-devel
wrote:
>
> Part of the problem there was MS didn't have full copyright.
[[citation needed]]
Who else?
There were 3rd party extras in later DOSes: disk compression, memory
optimisers, anti-virus, and things. But not in the DOS 3 or 4
On Mon, 16 Dec 2024 at 19:44, tom ehlert via Freedos-devel
wrote:
>
> unfortunately this is completely irrelevant as the only need is for an OS
> that allows
> to play old games. So this requires Windows 3.x.
For whom?
Are you saying that the only use for FreeDOS is to play old games? I
don't a
On Mon, 16 Dec 2024 at 19:12, Danilo Pecher via Freedos-devel
wrote:
> There's simply no demand for something like that.
> FreeDOS itself is a niche product to begin with.
I don't know -- there's WINE. It runs 16-bit apps on 64-bit OSes,
which is more than Windows itself can or will.
--
Liam Pr
On Mon, Dec 16, 2024 at 4:36 PM Bruce Axtens via Freedos-devel
wrote:
>
> Thanks for all the chat about the other issues. Regarding these ones
> however there hasn't been much. Do I assume that Freemacs isn't a thing
> anymore and that everything that needs a maintainer has one?
>
>
> * Apply some
Thanks for all the chat about the other issues. Regarding these ones
however there hasn't been much. Do I assume that Freemacs isn't a thing
anymore and that everything that needs a maintainer has one?
* Apply some much-needed patches to the Freemacs editor
Where's the list of fixes?
*
Hi!
It's probably time to kill (or at least build and deliver by
default) the KSSF variant (to half build times)
I disagree. On systems without XMS, KSSF is a lot better than XMSSWAP.
Also, if the problem is that 16 languages do 16 compiles, while each
of them concatenates the SAME compiled
S developers.
Cc: Danilo Pecher
Subject: Re: [Freedos-devel] Contributing
Well, in extremis you could go down the ReactOS route and reverse
engineer Windows 3. But I doubt you'd be doing it for much more than
shits and giggles. There's simply no demand for something like that.
FreeDO
>> This is not about "something with graphics and mouse".
>>
>> It's like FreeDOS vs. MSDOS: it's only DOS if it executes Norton Commander.
>>
>> And it's only Windows if it executes MS Word and a bazillion windows games.
> I think you misinterpret me.
no.
> (I suspect it's ashamed of the code
Cell phone - harder to be "proper".
On Mon, 16 Dec 2024, Liam Proven via Freedos-devel wrote:
I think you misinterpret me.
I think there is basically zero chance MS will make Windows 1, 2 or 3 FOSS.
(I suspect it's ashamed of the code, if it still has it at all. FOSS
MS-DOS 4 only happened be
Well, in extremis you could go down the ReactOS route and reverse
engineer Windows 3. But I doubt you'd be doing it for much more than
shits and giggles. There's simply no demand for something like that.
FreeDOS itself is a niche product to begin with.
On Mon, 16 Dec 2024 at 19:23, Liam Proven via
On Mon, 16 Dec 2024 at 18:09, tom ehlert via Freedos-devel
wrote:
> This is not about "something with graphics and mouse".
>
> It's like FreeDOS vs. MSDOS: it's only DOS if it executes Norton Commander.
>
> And it's only Windows if it executes MS Word and a bazillion windows games.
I think you m
Hallo Herr Liam Proven via Freedos-devel,
am Montag, 16. Dezember 2024 um 18:22 schrieben Sie:
> On Sun, 15 Dec 2024 at 07:25, Steve Nickolas via Freedos-devel
> wrote:
>>
>>
>> I mean, something like a free Windows 3.0 or a free Desqview/X would be
>> nice, but eh.
> It would indeed.
> The th
On Mon, 16 Dec 2024 at 17:45, Steve Nickolas via Freedos-devel
wrote:
>
>
> Less more, more less... Though I don't deny that PC-GEOS isn't bad for
> what it is.
Don't get me wrong, I'd _love_ a FOSS DESQview/X. I was very impressed by that.
However, I recall a petition to Symantec to open-source
On Mon, 16 Dec 2024, Liam Proven via Freedos-devel wrote:
On Sun, 15 Dec 2024 at 07:25, Steve Nickolas via Freedos-devel
wrote:
I mean, something like a free Windows 3.0 or a free Desqview/X would be
nice, but eh.
It would indeed.
The thing is, it more or less exists: it's PC GEOS.
https
On Sun, 15 Dec 2024 at 07:25, Steve Nickolas via Freedos-devel
wrote:
>
>
> I mean, something like a free Windows 3.0 or a free Desqview/X would be
> nice, but eh.
It would indeed.
The thing is, it more or less exists: it's PC GEOS.
https://github.com/bluewaysw/pcgeos
--
Liam Proven ~ Profil
On Sun, 15 Dec 2024 at 06:44, Ben Collver via Freedos-devel
wrote:
> I think HP's method of "booting" FreeDOS on amd64 hardware is interesting. I
> would like to see a tightly integrated, special purpose Linux distro for
> this; the minimum required to present a guest BIOS plus features to en
> Am 15.12.2024 um 18:01 schrieb tom ehlert via Freedos-devel
> :
>
> and replace it by the SVARDOS command.com which should also be made efault on
> 8086 and 80186 machines as they don't have XMS memory.
That may make adjustments to the batch files shipped with FreeDOS necessary.
There are
On Sun, 15 Dec 2024, Danilo Pecher via Freedos-devel wrote:
I don't think you'll find too many 8086 machines these days, let alone
80186. I fact I saw such a thing once in my entire life. A
Triumph-Adler with an amber monochrome monitor, which I found so cool,
I still change the font settings to
> I re-ran this under a real machine: i5-13500, Win 11, NVMe SSD. Compile time
> is down to 10 minutes.
I didn't immediately recognize this: the ability to (cross-)compile FreeDOS
stuff on a 64-bit machine.
Now if you have a network connection (or equivalent) between your FreeDOS VM
and Win
I still use lots of Amstrad PC-1512 and PC-1640 with and 8086 CPU (in fact a
NEC V15).
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Remitente:Danilo Pecher via Freedos-devel
Destinatario: Technical discussion and questions for FreeDOS developers.
Fecha:
I don't think you'll find too many 8086 machines these days, let alone
80186. I fact I saw such a thing once in my entire life. A
Triumph-Adler with an amber monochrome monitor, which I found so cool,
I still change the font settings to amber-on-black 30 years later on
whatever system I'm working o
>> Ok, then I have some numbers for you: FreeDOS kernel builds in 4 seconds,
>> FreeCOM builds in 41 minutes, on the same machine. To be fair, this includes
>> the executables for all languages and the XMSSWAP, KSSF variants (which in
>> the previous mail I referred to as memory strategies).
Open Watcom makefiles are somewhat peculiar about non-tangible build
targets, like 'clean:' for instance. You have to use a proprietary
macro to make that work, but I can't quite remember it right now. It
was something like %SYMBOLIC% or somesuch, else the Watcom make
rebuilds stuff unneccessarily
I re-ran this under a real machine: i5-13500, Win 11, NVMe SSD. Compile time is
down to 10 minutes. As I now have the build files on my disk, I uploaded them to
https://nextcloud.iww.rwth-aachen.de/index.php/s/93ikMxF3fPMcNSY
in case one wants to test the latest FreeCOM available from
https://g
Hi!
this includes the executables for all languages and the XMSSWAP, KSSF variants
so you are rebuilding freecom 32 times...
I would have hoped and vaguely remembered that FreeCOM builds
as a binary blob to which you can append message text blobs
to build specific language versions. My anc
Hallo Herr Bernd Böckmann via Freedos-devel,
am Sonntag, 15. Dezember 2024 um 13:36 schrieben Sie:
>> Am 14.12.2024 um 23:58 schrieb tom ehlert via Freedos-devel
>> :
>>
>> I never measured this.
> Ok, then I have some numbers for you: FreeDOS kernel builds in 4 seconds,
> FreeCOM builds in
41 minutes to build is quite a plank... You can compile a Linux kernel
faster than that. Are you sure that there isn't something else
interferring with it? Something that compiles for that long is usually
a massive chunk of code.
On Sun, 15 Dec 2024 at 13:37, Bernd Böckmann via Freedos-devel
wrot
> Am 14.12.2024 um 23:58 schrieb tom ehlert via Freedos-devel
> :
>
> I never measured this.
Ok, then I have some numbers for you: FreeDOS kernel builds in 4 seconds,
FreeCOM builds in 41 minutes, on the same machine. To be fair, this includes
the executables for all languages and the XMSSW
I guess we were all at this point at some time or other.when we
thought we had a brilliant idea and then realised that our plans were
more than just a little fanciful. I spent the best part of 1992 and
1993 writing a rather fancy GUI library that worked on EGA, VGA, a
weird-arse 512K Realtek SVGA
On Sat, 14 Dec 2024, Ben Collver via Freedos-devel wrote:
Thanks for the explanation. Reminds me of folks who made grand plans
for programming projects and perhaps wrote some scaffolding code, but
never finished anything. A whole new GUI or multitasking system built
on top of DOS would be gr
On Sat, 14 Dec 2024, Steve Nickolas via Freedos-devel wrote:
> But this whole thing I've seen about people trying to turn FreeDOS
> into a modern OS with a GUI, multitasking and native AMD64
> support and failing because they can barely write hello world...it's
> because they've got stars in their
ah ok ok ill do that then~ thanks for the info! 💛️
On Sat, 2024-12-14 at 16:45 +0100, Danilo Pecher via Freedos-devel
wrote:
> Dflat+ is a dos text mode library that is styled to mimick the
> Microsoft windows API.
>
> Some info can be found here :
> https://pushbx.org/ecm/editsrc/DOC/DFLATP/DFP10
On Sat, 14 Dec 2024, Ben Collver via Freedos-devel wrote:
A lot of FreeDOS novices seem to want to turn it into Linux, the same
way a lot of Linux novices seem to want to turn it into Windows - and
I think it probably galls some of the old-timers here.
Seems to me there is an old tradition of
On Sun, 15 Dec 2024, tom ehlert via Freedos-devel wrote:
Hallo Herr Steve Nickolas via Freedos-devel,
am Sonntag, 15. Dezember 2024 um 01:09 schrieben Sie:
Also for what it's worth, if Microsoft ever opens the 5.0 sources (this isn't a
non-zero chance) that may be enough to use its version
> A lot of FreeDOS novices seem to want to turn it into Linux, the same
> way a lot of Linux novices seem to want to turn it into Windows - and
> I think it probably galls some of the old-timers here.
Seems to me there is an old tradition of trying to turn DOS into Unix that
predates even MS-DOS
Hallo Herr Steve Nickolas via Freedos-devel,
am Sonntag, 15. Dezember 2024 um 01:09 schrieben Sie:
> Also for what it's worth, if Microsoft ever opens the 5.0 sources (this isn't
> a non-zero chance) that may be enough to use its version of command.com in
> lieu of FreeCOM. 4.01's isn't enoug
Danilo,
> Tom, what's the joke with the references to Linux?
Not Linux specifically. ANY decent interpreter ready to be ported would do.
I just don't expect someone writing something new from scratch. And DOS
certainly
has not been waiting for REXX and friends.
Tom
> Not that I would
> mind.
On Sun, 15 Dec 2024, Danilo Pecher via Freedos-devel wrote:
Tom, what's the joke with the references to Linux? Not that I would
mind. I've run Linux since 1994. Took home an early Slackware system
on 64 floppy disks, had to write an X11 driver for my weird-ass 512K
Realtek SVGA card and then rui
Tom, what's the joke with the references to Linux? Not that I would
mind. I've run Linux since 1994. Took home an early Slackware system
on 64 floppy disks, had to write an X11 driver for my weird-ass 512K
Realtek SVGA card and then ruined my eyes looking at 1024x768 pixels
interlaced, but why woul
> I'd agree with Tom here. Reinventing the wheel makes little sense.
> After all, one of the points of FreeDOS is being a free replacement
> of, well DOS, so you shouldn't really need a replacement for something
> that has worked fairly well since the Romans left.
> In fact, I'm not even sure we
> A build system overhaul would also be nice. As it is now, nearly a hundred C
> files are compiled, each containing a single translated string.
So what? It's done automatically, and a complete rebuild (which is needed only
once due to MAKE) takes
(in a Windows XP DOS box with decent *write
Good grief. Have you even had a look at the sources? Most of it iis
stuff that was written when people were still carrying their wives
over their shoulders and they used to club mammoths for a meal. You
don't need a C20 compiler to build most of the GNU tools. FreeDOS is a
free implementation of a
Ah! I misunderstood entirely. Yep, that's a problem that needs
rectification. That makes more work for the whole build system due to
the fixed overhead of dealing with each compilation unit, as well as
the effort that must be exerted by the linker at the end.
The only reason that comes into
> I was talking about a hundred .C files PER LANGUAGE.
Ah! I misunderstood entirely. Yep, that's a problem that needs
rectification. That makes more work for the whole build system due to the
fixed overhead of dealing with each compilation unit, as well as the effort
that must be exerted by the l
On 14.12.2024 21:48, Kirn Gill II via Freedos-devel wrote:
Because that's how the vast majority of projects are organized; The
text strings for each supported language live in their own separate
translation files.
This is NOT what I was talking about. I was talking about a hundred .C
files
> Most GNU tools, especially those that you would use outside of a gcc dev
enironment, don't require gcc.
Immediate message before yours has:
> Or they at least assume a more recent-standard Unix-like compiler.
So that was addressed before you got there.
> I can say that with some confidence,
I'd agree with Tom here. Reinventing the wheel makes little sense.
After all, one of the points of FreeDOS is being a free replacement
of, well DOS, so you shouldn't really need a replacement for something
that has worked fairly well since the Romans left.
In fact, I'm not even sure we should go t
On 14.12.2024 18:41, tom ehlert via Freedos-devel wrote:
however, teaching freecom.com new tricks would be welcome, even if pretty much
nobody
would ever know about and use them.
A build system overhaul would also be nice. As it is now, nearly a
hundred C files are compiled, each containing
On 14.12.2024 18:22, Danilo Pecher via Freedos-devel wrote:
Unless any program uses gas' AT&T assembler syntax there should be no
source that requires gcc to compile. Everything else can be handled
via #ifdef's.
Technically yes, but good luck convincing people to make the required
changes whe
> * Create a new alternative shell, similar to COMMAND.COM but with expanded
> BAT programming.
creating a *new* command.com is a really idiotic idea. the existing freecom.com
is stable, tested,
and mostly bugfree. Why would someone even get the idea to create a *new* one
(including investing
Jim, if you have a package name at hand where you think it is
dependent on gcc, let me know. I'll port it to OWC and we may even
work out some general guidelines on how to 'port' sources from gcc to
OWC. I could use a good challenge. Ever since I learned C on Dec. 31st
1990, I've made it a traditio
Unless any program uses gas' AT&T assembler syntax there should be no
source that requires gcc to compile. Everything else can be handled
via #ifdef's.
On Sat, 14 Dec 2024 at 18:18, Jim Hall via Freedos-devel
wrote:
>
> On Sat, Dec 14, 2024 at 9:34 AM Danilo Pecher via Freedos-devel
> wrote:
> >
Ah, now I'm getting where you come from. The question is, why would
anyone need it? The GNU tools that actually make sense under FreeDOS:
make, patch, flex, bison, findutils don't really need gcc.
Realistically only things like binutils should really need gcc because
of the use of AT&T assembler s
On Sat, Dec 14, 2024 at 9:34 AM Danilo Pecher via Freedos-devel
wrote:
>
> As I wrote in my reply to Jim's email, I don't think introducing
> additional toolchains makes any sense. In fact it would be a good idea
> to have all 'official' packages that are based on C compile with OWC.
> I don't kno
Jim Hall wrote:
>> Several of the GNU tools assume you're compiling with GCC. Or they at
>> least assume a more recent-standard Unix-like compiler.
>>
>> In these cases, trying to port a GNU utility to FreeDOS using OpenWatcom
>> can be a lot harder than just compiling it with a GCC compiler like
>
As I wrote in my reply to Jim's email, I don't think introducing
additional toolchains makes any sense. In fact it would be a good idea
to have all 'official' packages that are based on C compile with OWC.
I don't know if that has changed, but I remember MKEYB at some point
required Turbo-C to comp
i need help with a new freedos program! :D?
it is https://github.com/sparky4/mh
i need to know about dflat+ and how to use it~
i cannot seem to find documentation
we also need more 16 bit utilities <3
On Sat, 2024-12-14 at 18:02 +0800, Bruce Axtens via Freedos-devel
wrote:
> Assuming I'm an exp
Dflat+ is a dos text mode library that is styled to mimick the
Microsoft windows API.
Some info can be found here :
https://pushbx.org/ecm/editsrc/DOC/DFLATP/DFP100.HTM
On Sat, 14 Dec 2024 at 16:38, victoria crenshaw via Freedos-devel
wrote:
>
> i need help with a new freedos program! :D?
>
> it
Hi Jim,
I don't think it is a good idea to introduce a second toolchain. Most
GNU tools, especially those that you would use outside of a gcc dev
enironment, don't require gcc. I can say that with some confidence,
because I compiled them using non-gcc compilers under AIX and HP-UX in
the past, an
Hi,On Dec 14, 2024, at 9:13 AM, Bruce Axtens via Freedos-devel wrote:This IA-16 GCC? https://sourceforge.net/p/freedos/news/2022/01/ia-16-gcc-toolchain-and-libi86-library-jan-2022-version-BruceThe one you want used to be on GitHub [1], However, the developer moved most of the IA16 stuff to GitLab
This IA-16 GCC?
https://sourceforge.net/p/freedos/news/2022/01/ia-16-gcc-toolchain-and-libi86-library-jan-2022-version
-Bruce
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Several of the GNU tools assume you're compiling with GCC. Or they at least
assume a more recent-standard Unix-like compiler.
In these cases, trying to port a GNU utility to FreeDOS using OpenWatcom
can be a* lot harder* than just compiling it with a GCC compiler like IA-16
GCC. (Djgpp is great to
I have to admit, I'm rather confused about the gcc IA-16 thing too.
Jim seems to like it a lot, but Watcom code runs on all processors
too, provided you use the proper options to have it compile for the
lowest common demoninator, which would be the 8086.
On Sat, 14 Dec 2024 at 11:04, Bruce Axtens
Hi,
On Sat, Nov 8, 2014 at 4:39 PM, Rugxulo wrote:
>
> On Sat, Nov 8, 2014 at 3:54 PM, Denis St-Lau wrote:
>>
>> Is xkeyb a freedos managed program or a third party program?
>> http://www.freedos.org/software/?prog=xkeyb
>>
>> I want to contribute additional keyboard definition .KEY files bu
Hi,
On Sat, Nov 8, 2014 at 3:54 PM, Denis St-Lau wrote:
>
> Is xkeyb a freedos managed program or a third party program?
> http://www.freedos.org/software/?prog=xkeyb
AFAIK, XKEYB is "obsolete" in lieu of FD KEYB, which was rewritten and
(more or less) still maintained by Aitor. Henrique is
Hi,
On Mon, Sep 3, 2012 at 2:14 PM, Zoltán Bacskó wrote:
>
>> Re: Turbo51, I've seen it but am quite skeptical.
>
> Would you tell me the reasons of your skepticism explicitly? I trust
> your judgement, so if there are serious issues with TPC16 I will
> remove the references from my site and prog
Hi !
> Doh! I wasn't sure, just assumed it was often surname first in
> Hungary. Anyways, I renamed it (as requested):
You know it right, but in english written e-mails I usually switch my
names according to english grammar rules. So it was a double switch :)
>Updated the .ZIP.
Thanks!
> Re: T
Hi,
On Sun, Sep 2, 2012 at 2:41 PM, Zoltán Bacskó wrote:
>
> Thanks for the mirroring! (anyway I would like to inform you that
> Zoltán is my forename and there are many Zoltáns in Hungary, so if
> more hungarian contributors will join, this could be a problem
> :).Bacsko, or falcosoft would be m
Hi!
Thanks for the mirroring! (anyway I would like to inform you that
Zoltán is my forename and there are many Zoltáns in Hungary, so if
more hungarian contributors will join, this could be a problem
:).Bacsko, or falcosoft would be more ideal)
Turning to the subject, I updated PWR to 1.2, now the
Hi,
On Fri, Aug 31, 2012 at 5:06 PM, Zoltán Bacskó wrote:
>
> According to your feedback the programs that most likely would be
> useful for FreeDOS are FAKEMEM, FVID, TSCDOS, PWR and LOWP.
> Thanks to your suggestions and informations four of them are now
> available with source code and JWASM c
Hi!
According to your feedback the programs that most likely would be
useful for FreeDOS are FAKEMEM, FVID, TSCDOS, PWR and LOWP.
Thanks to your suggestions and informations four of them are now
available with source code and JWASM compatibility.
For LOWP (athlon64 architecture low power util) to
Hi,
On Mon, Aug 27, 2012 at 9:08 PM, Zoltán Bacskó wrote:
>
>> P.S. TSCDOS sounds cool, has TASM sources, but I'm not sure how
>> accurate it is. Some processors (e.g. early Pentiums) eventually
>> reset, and later ones were wonky (non-atomic??) on SMP machines. I
>> guess that doesn't matter for
Hi!
> P.S. TSCDOS sounds cool, has TASM sources, but I'm not sure how
> accurate it is. Some processors (e.g. early Pentiums) eventually
> reset, and later ones were wonky (non-atomic??) on SMP machines. I
> guess that doesn't matter for us (and still seems to work correctly
> here). You should p
Hi !
> The Turion / Athlon64 mobile / Sempron / ... and Phenom tools
> to select lower voltages and clock frequencies sound exciting,
> could you extend them to also support AMD desktop processors?
> Does support depend on the mainboard chipset as well?
As far as I know none of them depends on c
Hi,
On Mon, Aug 27, 2012 at 3:43 AM, Zoltán Bacskó wrote:
>
> I have some DOS programs that can be useful for the FreeDOS community.
>
> http://falco1.heliohost.org/softwares.html#dos
>
> Regarding source codes I'm not familiar with Freedos coding standards,
> so If you need them contact me. (But
Hi :-)
> http://falco1.heliohost.org/softwares.html#dos
>
> Most of them mainly help the old DOS environment to cooperate better
> with modern processors (PWR or LOWP) or just help testing in some way
> (TSCDOS, CACHE).
The Turion / Athlon64 mobile / Sempron / ... and Phenom tools
to select low
84 matches
Mail list logo
