Re: [Freedos-devel] DOSLFN bugfix explanations and ideas - was: FreeDOS Interim Build T2508

DOSLFN might be covered using that brute-force approach, but the bug still exists ... INT 25 and 26 need some sort of integration with the existing buffer cache, otherwise every other user of INT 25 and INT 26 are still exposed. On Mon, Aug 18, 2025 at 3:08 PM Jim Hall via Freedos-devel < freedo

Re: [Freedos-devel] DOSLFN bugfix explanations and ideas - was: FreeDOS Interim Build T2508

I'm pretty certain that most DOS installations use a minimal setting for the BUFFERS= directive in config.sys. I've never seen anything over 30. Cache pollution is not an issue when your cache is already tiny - it's always being flooded. The BUFFERS cache primary exists to pick up the easy case

Re: [Freedos-devel] DOSLFN bugfix explanations and ideas - was: FreeDOS Interim Build T2508

This bug is terrible to read about. I still can't believe that INT 25 and 26 were not going through the buffer cache. Anything that blindly writes a sector before it reads it is broken, unless it's wiping something out. So you can assume that a read to a specific sector will always precede a wri

Re: [Freedos-devel] FreeDOS hidden partition types

ttps://github.com/FDOS/fdisk/blob/a6e3622c959707f1950df8ca4fe94046274ee1a9/doc/fdisk/history.txt#L1032 > [2]: > https://github.com/FDOS/fdisk/blob/a6e3622c959707f1950df8ca4fe94046274ee1a9/doc/fdisk/history.txt#L288 > > Bernd > > > > Am 07.07.2025 um 07:33 schrieb Michael Brutman

[Freedos-devel] FreeDOS hidden partition types

Over at the Wikipedia "List of partition IDs " I was surprised to find that FreeDOS FDISK has partition types defined for hidden FAT and Extended partitions that have different type numbers than the standard hidden versions of those. For example, FreeD

Re: [Freedos-devel] A break from my break

Hi Jerome, Congrats on getting back to the more technical side of the project. I hate to ask, but how much of this is documented? You might find another project and not want to be the distro maintainer forever ... -Mike On Sat, Apr 19, 2025 at 3:19 AM Jerome Shidel via Freedos-devel < freedo

Re: [Freedos-devel] FreeDOS 1.4

the FDNET package. The > README.TXT will say: > > FDNET uses DHCP.EXE created by Michael Brutman. > > > After some additional thought, this could confuse some readers into > thinking both are created by the same author. > So, I removed the "created by Michael Brutma

Re: [Freedos-devel] FreeDOS 1.4

So this is kind of funny ... The FDNET is basically a glorified BAT file. But it uses other things, so that creates complications: - It is using exactly one program from mTCP. The DHCP client. As a result, you are shipping all of the mTCP source code including a 250KB PDF file for dev

Re: [Freedos-devel] Fwd: Re: Problem with writes to NVMe disk

Are you sure about the non 512 byte sector support? The fake RAM disk that I show when a NetDrive drive letter is not connected uses four 64 byte sectors and FreeDOS can read it just fine. FreeDOS Chkdsk is limited to only working on 512 byte sector devices, but normal reads from the RAM disk wor

[Freedos-devel] "Stream of consciousness" posting

I'm not sure if other people are suffering from this or even noticing it, but the signal-to-noise ratio on this mailing list has dropped a lot lately. People should really be using formal bug tracking mechanisms. Emails to this list should not be micro-updates about the debugging or building proc

Re: [Freedos-devel] printer on FDT25xx and RC

I don't think it is correct to say that PRINT requires a dot matrix printer. Any printer connected to a parallel port that understands ASCII will work with PRINT. That includes many older laser printers. And if you have a virtual machine emulating a printer port, that opens it up to USB or netwo

Re: [Freedos-devel] New mTCP version available

On Jan 16, 2025, at 12:43 PM, Michael Brutman via Freedos-devel < > freedos-devel@lists.sourceforge.net> wrote: > > > > Hi Jerome, I know you are following ... ;-0 > > > > Please hold off on updating FreeDOS with this mTCP. It works but there > are some small bug

Re: [Freedos-devel] New mTCP version available

Wow, that's a release stopper right there ... I'll get to it immediately. In the interim I suggest that you just simply edit out the copyright statement from your copy of the batch file. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net

Re: [Freedos-devel] New mTCP version available

rsion (Oct 2024) than ship with the current version with its warts. Thanks, Mike On Tue, Jan 14, 2025 at 2:20 PM Michael Brutman wrote: > If anybody downloaded that code, please download it again from my site. I > made a small change to the zip files in the last hour for a bug I just >

Re: [Freedos-devel] New mTCP version available

If anybody downloaded that code, please download it again from my site. I made a small change to the zip files in the last hour for a bug I just found, and I'm too tired to bother to spin an entire new release. -Mike On Tue, Jan 14, 2025 at 9:45 AM thraex via Freedos-devel < freedos-devel@lists

Re: [Freedos-devel] Reminder: FreeDOS virtual get-together on Sunday

A Google account is not needed to use Google Meet as a participant. On Fri, Dec 6, 2024, 15:07 Wolf Bergenheim via Freedos-devel < freedos-devel@lists.sourceforge.net> wrote: > Hi Danilo, > > Last time(s) it was a Google Meet. Jim sends a link on Sunday. All you > need is a modern browser like F

Re: [Freedos-devel] FreeDOS 1.4 (recompiled upx)

I don't understand what the problem with UPX compressed executables is. The authors grant you (anybody) a license to compress a program using UPX and to make use of their decompression code (the stub) as long as you use their unmodified code. Non open code may use the stub for its intended purpos

Re: [Freedos-devel] fdnet.bat 'hang' on virtualbox if packet driver already loaded

The packet driver is doing the pause after it gives you the error message. That is working as intended and it has nothing to do with FreeDOS. On Sun, Nov 3, 2024 at 10:03 AM Paul Dufresne via Freedos-devel < freedos-devel@lists.sourceforge.net> wrote: > I have opened: > https://gitlab.com/Free

Re: [Freedos-devel] Source code distribution

On Sat, Sep 28, 2024 at 11:26 AM Steve Nickolas via Freedos-devel < freedos-devel@lists.sourceforge.net> wrote: > On Fri, 27 Sep 2024, Michael Brutman via Freedos-devel wrote: > > > There isn't much that can be done about the binaries getting stale, as a > > distribut

Re: [Freedos-devel] Source code distribution

I expect that all of the binaries and source are up to date at the time they are packaged, and that is a large effort - thank you! But some projects are still active and move independently of FreeDOS. mTCP (my project) is one such example, and with years between the FreeDOS releases the binaries

[Freedos-devel] Source code distribution

I read that there were some previous bad experiences with shipping source code separately, but I think it should be looked at again with a fresh set of eyes. Some reasons to ship source code separately: - *Few people are actually using it.* Most people are never going to look at the source

Re: [Freedos-devel] Packages on the FreeDOS distribution

I have a personal bias here, but I think that basic network connectivity should be part of the standard packaging and not relegated to a bonus CD. There are other things that should be moved first. For example, mTCP is 3.5MB and that includes the documentation, which is several times larger than t

Re: [Freedos-devel] Chkdsk troubles with small sector sizes

Nevermind, I found it in the CHKDSK source int ENGINE/LOW/RDWRSECT.C if ((*handle)->BytesPerSector != 512) { SetFTEerror(FTE_INVALID_BYTESPERSECTOR); RETURN_FTEERR(FALSE); } FreeDOS Chkdsk can't handle anything other than 512 byte sector sizes. -Mike __

[Freedos-devel] Chkdsk troubles with small sector sizes

Is the CHKDSK.COM that is included with FreeDOS 1.3 restricted to only checking block devices that use 512 byte sectors? I have a RAM disk device driver that works with FreeDOS and PC-DOS when it is compiled with 64 byte, 128 byte, 256 byte, and 512 byte sectors. (By works I mean it is readable a

Re: [Freedos-devel] development and advertising plan

At some point I'm beginning to think this email list needs to be moderated. The amount of noise coming through is getting pretty high. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos

Re: [Freedos-devel] FreeDOS on Pocket386 (follow-up)

I have a report from somebody who has used mTCP with an NE2000 type card on the machine through the adapter - it worked. SLIP or PPP through the serial port should also work fine. On Mon, Jun 17, 2024 at 6:47 PM Jerome Shidel via Freedos-devel < freedos-devel@lists.sourceforge.net> wrote: > > >

Re: [Freedos-devel] FreeDOS Interim Build T2310 - no free space on CD

You both can be right. I think there is a reasonable split here: [1] Smaller languages (BASIC, Pascal?) basically fall in the same class as scripting languages and are useful to have available. [2] Huge developer environments make more sense on a more capable operating system where you cross comp

Re: [Freedos-devel] FreeDOS Interim Build T2310 - no free space on CD

There is no point in punishing everybody by shipping tools that most people don't use. You can probably count all of the active DOS developers on your fingers and toes. All of the various tools and compilers remain available for download. Not being on the CD image is not the barrier it used to b

Re: [Freedos-devel] FreeDOS virtual get-together on Sunday (reminder)

I've used Google Meet for this type of meeting before. It's entirely web based so there is no annoying desktop specific client to install. And even though it is a Google product, it can be used without a Gmail ID. I've hosted several long meetings for the PCjr users with it and it works well.

Re: [Freedos-devel] dir issues

Microsoft Engineer "Steve Ballmer" ? Ballmer was on the business side of things at Microsoft. He didn't write code. On Tue, Aug 8, 2023 at 11:27 AM M. J. Bethlehem via Freedos-devel < freedos-devel@lists.sourceforge.net> wrote: > > > The original plan was to let Windows fade away after 2.x;

Re: [Freedos-devel] CD-ROMs was ANSI for DOS

Many early CD-ROM drives used on PCs were SCSI, and all of those drivers work on the XT class (8088/8086/V20) CPUs. There were a lot of devices from Future Domain, Trantor, and Adaptec. The Adaptec cards generally required a 16 bit bus but the software runs fine on machines with 8 bit slots. (I'

Re: [Freedos-devel] ANSI for DOS

In the thread on the other forum I pointed out that remapping the cursor keys to generate ESC sequences instead of passing through the {0, scan code} value was going to break other DOS software. So while adding the ESC sequences to FreeCOM seems harmless, it also really only benefits people who ar

Re: [Freedos-devel] libm-0.3

Is this really appropriate here? (I don't think so.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

Tom, We agree .. I just can't write a book via email describing all of the nuances. Even on a single CPU core the performance should be better, but I suspect what we have is a "bogomips" like benchmark which is good at measuring the effective clock rate, not the actual processing power of the th

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

Your measurement methodology needs help? The i5 is capable of far more work than the K6-2-350. What you are doing is comparing a bus to a passenger car and stating that they both are effective at carrying one person, and therefore the bus has no additional value. When running a simple single-thr

[Freedos-devel] CPU architecture (Was Re: DOS Swappable Data (SDA) Area

This email thread is driving me nuts because so much of it is wrong. *Speculative execution has nothing to do with caching.* Caching is about keeping often used data as close to the CPU execution unit as possible so that the CPU execution unit doesn't stall for lack of data. But the cache is cle

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

On Mon, Mar 20, 2023 at 3:05 PM Bret Johnson wrote: > > Even though a 350 MHz K6-2 is WAY faster than my 3.3 GHz i5? And again, I > know it doesn't make any sense, but it's still true. > > As far as I can tell, the Emperor has no Clothes. > > I'm confused by this. You are claiming that a 350 Mh

Re: [Freedos-devel] watcom, was Re: Booting and FDAPM

+1 - Open Watcom 1.9 is stable and safe. I think those factors make it the default for inclusion in a distribution. Something actively under development and in between releases sounds like a bad idea. On Sat, Mar 18, 2023 at 5:42 AM wrote: > Hi Bernd, > > > On Mar 17, 2023, at 2:12 PM, Bernd B

Re: [Freedos-devel] FDISK: how to handle sector size != 512?

I don't think that sector sizes other than 512 are supported for hard drives. (Floppy drives are a different story.) Things that used non-standard sector sizes had to supply their own formatting routines and their own BIOS extensions. The original Bernoulli box is a good example: it used 256 byt

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

I'm going to try to make this very simple ... To be re-entrant (in the context of code) means that if a function is running and by some path it winds up being called again, it will work. This path might be through the normal call chain on the stack or through interrupts and signal handlers. If a

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

Which highlights my point about using the correct terminology - emulators are not virtual machines. DOSBox just happens to do both. -Mike On Thu, Mar 9, 2023 at 4:52 PM Ben Collver wrote: > Michael Brutman wrote: > > > You can't refer to DOSBox or other things like it as vi

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

Brett, I'm going to make this really simple ... you are using the word "virtual" in an overly generalized sense. That is not compatible with highly technical discussions, wherever everybody needs to use the same terminology in order to be understood and make progress. This is really simple - th

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

wrote: > On Wed, 8 Mar 2023, Michael Brutman wrote: > > > Sorry, we have a terminology issue here. (Again.) > > > > A Virtual Machine for the rest of us is something like VMWare, Qemu, > > VirtualBox, etc. - something that simulates a real machine. You load a > &

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

Sorry, we have a terminology issue here. (Again.) A Virtual Machine for the rest of us is something like VMWare, Qemu, VirtualBox, etc. - something that simulates a real machine. You load a real operating system in it and the operating system generally doesn't know or care that it's actually in

Re: [Freedos-devel] DOS Swappable Data (SDA) Area

On Tue, Mar 7, 2023 at 7:13 AM Bret Johnson wrote: > > The way I'm trying to getting around that problem is to monitor the InDOS > and Critical Error flags and some other things (like INT 28h). But I'm > sometimes getting false readings, especially in some Virtual Machines. For > example, some

Re: [Freedos-devel] Needs testing: SJGPlay

In the year 2023 does FreeDOS really need a command line utility to tell a CD-ROM to play a music track? Except for the novelty of it, I don't know anybody who would listen to music this way. It's an anachronism from the mid 1990s. Mike ___ Freedos-de

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

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 expe

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

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 othe

Re: [Freedos-devel] "FreeDOS Next" packages

How about something very radical - cutting FreeDOS back to the bare operating system, and just offering the other software as user-installed downloads as it was originally packaged? In ye olde days people purchased DOS, installed it, and then installed their own software using the original install

Re: [Freedos-devel] Thinking about FreeDOS 2.0

Please forgive me for getting lost on this thread, but what exactly is the problem that we are trying to solve? Are we trying to make things simpler for novice users? Advanced users? FreeDOS maintainers (Jerome in particular) ? -Mike ___ Freedos-devel

Re: [Freedos-devel] Any package updates for FreeDOS 1.3?

Thanks for the explanation. The separate directory is perfect, and also logical/expected. While the current FreeDOS is up to date with mTCP, that never lasts. And then we have the people who installed FreeDOS years ago, which is why I keep getting support questions for ancient versions. I think

Re: [Freedos-devel] Any package updates for FreeDOS 1.3?

I'm working on a new mTCP version, and this thread reminded me to ask about a problem. I update mTCP more often than FreeDOS gets updated; it's under active development and I need to get fixes out. Where this becomes a problem is that I often see people using the 2013 version of mTCP because they

Re: [Freedos-devel] extending chkdsk to fat32

I have machines that have hardware EMS. What I just read above is that FreeDOS shouldn't bother with EMS support because it is obsolete. And that there is only one user who uses EMS and he doesn't use FreeDOS, so it really doesn't matter. Ok. I give up. No more 16 bit talk and FreeDOS in the s

Re: [Freedos-devel] extending chkdsk to fat32

EMS can work on 8088 class machines, given the right add-on memory card. DPMI will never work on that kind of machine. -- ___ Freedos-devel mailing list Freedos-devel@lists.source

Re: [Freedos-devel] FreeDOS

t; I'd also appreciate "advanced" features for the case when you want to > >> install e.g. one or two things from NET or UTIL in addition to BASE, but > >> not everything. Yes, there's FDNPKG, but what when you don't have a 386+ > >> and an

Re: [Freedos-devel] FreeDOS

+1 Also, I personally think the 'batch file setup' idea is deeply flawed. There is a balance to achieve. The more complicated a task is, the more the complexity should be hidden away in a few key places. An operating system is the canonical example of this; we build operating systems so that pe

Re: [Freedos-devel] Sorry for being inactive

I'm really laughing my -ss off about this thread ... if you had been hit by anything other than a script kiddie I doubt that you would know it. The fact that you are getting emails is even funnier. Since you are going to the police and hoping for an investigation, I'd recommend that you stop pos

Re: [Freedos-devel] FDNPKG16 port!

I would continue to use WatTCP too. The real benefit of your work will be in enabling 16 bit machines to use fdnpkg. Changing stacks should not be required unless 16 bit WatTCP is broken. On Oct 6, 2015 15:05, "Steve Nickolas" wrote: > On Tue, 6 Oct 2015, sparky4 wrote: > > > ah ok!! > > > > i

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

Open Watcom will generate 16 bit DOS binaries from any host platform that you run it on. All of my code is developed on Windows 7 using Open Watcom, generating code for the 16 bit DOS target. I use DOSbox for quick testing. For this code a virtual machine is appropriate. Setup networking in the

Re: [Freedos-devel] exfat support from android linux for freedos sdxc support and more?

+1 Writing specs is useless if you are not going to put the engineering effort in. Let's see FreeDOS 1.2 released sometime soon. I don't want to sound harsh, but "drawing specs" is easy, anybody can do that. Do some code that actually works, then we're talking. Mateusz On 25/09/2015 03:44, Me

Re: [Freedos-devel] FDNPKG16 port!

mTCP won't be the problem - it is already 16 bit. The problem is that FDNPKG is designed with a 32 bit address space as a base assumption. The data structures are being stored in memory and there is an assumption that the size of the data structures will be quite large. I've discussed this with

Re: [Freedos-devel] FDI 1.2 Questions?

I'm having a hard time trying to understand the requirement that the install should be super simple. At this point in time, anybody installing any version of DOS is probably not a novice. An installer should give you a choice of things to install, broken down by groups and packages. Usually ther

Re: [Freedos-devel] mTCP/IP stack by M Brutman is now closed source

at 8:09 AM, Bruno Félix Rezende Ribeiro < oitofe...@gnu.org> wrote: > Em Mon, 7 Sep 2015 15:37:18 -0700 > Michael Brutman escreveu: > > > If the lack of source code prevents you from using mTCP I regret that > > and I encourage you to question your assumption that without

Re: [Freedos-devel] mTCP/IP stack by M Brutman is now closed source

Hi, Please don't panic. There are better things to worry about. Just to clarify: - The source for the 2013-05-23 version is available and always will be. That particular release was probably near perfect because very few people ever ask for more features or send bug reports. - The source for m

Re: [Freedos-devel] stupid question

Tom's method of correcting your behavior was, shall we say, blunt, but the underlying criticism is still valid for any mailing list. - Subject lines should reflect the subject. Start a new thread if necessary. - If you are asking for help you should include whatever diagnostic information you ma

[Freedos-devel] FreeDOS 1.2 (Was: Re: 32-bit FreeDOS

ackages! :-D ) will be available by the end of the month. > > > > On Wed, Jun 17, 2015 at 10:00 PM, Michael Brutman > wrote: > >> Before you get too involved with a 32 bit DOS-like operating system can >> you update

Re: [Freedos-devel] 32-bit FreeDOS

Before you get too involved with a 32 bit DOS-like operating system can you update us on your progress with FreeDOS 1.2? I thought you were working on that too. On Jun 17, 2015 11:07 AM, "Mercury Thirteen" wrote: > I think there's been sufficient time for everyone who is interested to > reply. B

Re: [Freedos-devel] Clock

Let's think about this critically. Is somebody really going to use a personal computer or a virtual machine running DOS to perform the functions of an alarm clock in the year 2015? On Thu, Jan 29, 2015 at 5:30 PM, JAYDEN CHARBONNEAU < jcharbonnea...@cpsge.org> wrote: > Hello!I was wondering,is

Re: [Freedos-devel] Instituting a vetting process for FreeDOS software

I almost feel like I should apologize for opening the can of worms. Some thoughts: - Software contributed to FreeDOS needs to be free. (We already require this. No problem ...) - Contributed code should be free from contamination from non-free code. Looking at leaked MS-DOS source code is enou

Re: [Freedos-devel] Instituting a vetting process for FreeDOS software

This is a slippery slope. While I don't use Turbo C anymore for mTCP, I did use it and still use it for smaller projects. It is commercial but readily available for little money and it does not have any royalty encumbrances. On Jan 26, 2015 3:44 AM, "Jim Hall" wrote: > > On Jan 26, 2015 4:41 AM

Re: [Freedos-devel] Instituting a vetting process for FreeDOS software

Yeah, I'm not too keen on starting that pissing contest ... especially for a hobbyist project. Most open source projects go by reputation; you gain 'cred' by submitting good patches/software/documentation/etc. I was thinking more along those lines. On Sat, Jan 24, 2015 at 3:52 PM, Ralf Qui

Re: [Freedos-devel] Instituting a vetting process for FreeDOS software

I was trying to be more sensitive than to use "crapware", but yes, I understand. I think that for something to be included it needs to have the correct license, it needs to do what it says it does, it needs to be of some value to a larger audience and not just fill a small niche. And I'm also sug

Re: [Freedos-devel] Instituting a vetting process for FreeDOS software

es most > people would use. Is that still the right distinction? (I think yes.) > > jh > On Jan 24, 2015 12:39 PM, "Michael Brutman" wrote: > >> >> I think we need a vetting process for new software that developers want >> to include with FreeDOS. I'm glad

[Freedos-devel] Instituting a vetting process for FreeDOS software

I think we need a vetting process for new software that developers want to include with FreeDOS. I'm glad that people are asking to be included, but there is a certain level of review that we should be doing. - The source code should be reviewed for obvious problems; back doors and security probl

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

You have my email address. Say them in private if you like. In the past few days you have drawn false analogies to other operating systems, demonstrated a lack of understanding of the origins of FreeDOS or what it is, and made wild statements about what a non-existent piece of software could do.

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

27;s 32 bit it's not FreeDOS. Go start a project and do some work toward realizing your vision, but please stop calling it FreeDOS. And stop pretending to be an OS architect. On Tue, Jan 6, 2015 at 8:44 AM, Mercury Thirteen wrote: > On Mon, Jan 5, 2015 at 9:14 PM, Michael Brutman >

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

Bringing things back to reality: Options 1, 2, and 3 do not exist and are not likely to exist for a few years even after somebody actively starts working on them. Options 1 and 2 can not promise "100% compatibility with both DOS applications and the full range of PC hardware" when they are not ev

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

I don't think I missed anything. In his most recent post Mercury Thirteen spoke of multiple 16 bit programs running at the same time. That it's not EMM386 ... that is a supervisor layer for multiple virtual DOS machines.

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

How is using the Virtual 8086 mode any different than what OS/2 2.x provided? It too ran 16 bit DOS and DOS applications in Virtual 8086 mode, making OS/2 serve as the supervisor layer. The advantage would be that you would be able to run several DOS programs on a single machine at once. Each DO

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

: > > On Jan 2, 2015, at 6:29 PM, Michael Brutman wrote: > > People are free to fork off and make a new project based on FreeDOS. No > > problem there. But once you break compatibility with existing > > applications, you lose a lot of your potential user base. And as soon as &g

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

FreeDOS is, by definition, a re-implementation of DOS. If you read the specification on the Wiki the kernel targets MS-DOS 3.3 and the applications target MS-DOS 6.22. There is no need to modernize FreeDOS. Anything 32 bit would be radically different and thus is a different project. IBM and Mic

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

What's the difference between FreeDOS 1.1, 1.2 and 1.3? Bug fixes, updates to the user space packages, improvements to the installer, and possibly improvements to the packaging. I reject the argument that FreeDOS needs to evolve and leave its 16 bit roots behind, similar to the way MacOS did. Ma

Re: [Freedos-devel] FreeDOS 1.2 and 2.0 roadmap discussion

Thanks for the update - I'm not on Facebook so I can't see the discussion. What follows is my personal opinion/rant ... What FreeDOS is: FreeDOS is an open source re-implementation of DOS (PC-DOS and MS-DOS). I was careful not to use the word "clone" which would imply that everything has to be

Re: [Freedos-devel] Kickstarter project for FreeDOS 2.0

Somebody should talk to HP and see what FreeDOS 2.0 includes. They are already shipping machines that support it: http://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c04027658&DocLang=en&docLocale=en_US&jumpid=reg_r1002_usen_c-001_title_r0001 On a more serious note, somebody should tr

Re: [Freedos-devel] Working on FreeDOS 1.2

As much as I like my 16 bit machines, I'm open to making mTCP 32 bit friendly. The code is very careful with data types - I never use "int" when the number of bits matters. The trouble spots are going to be the IP checksum routine which is hand-optimized assembly, my time of day code which looks

Re: [Freedos-devel] Kickstarter project for FreeDOS 2.0

I am a little skeptical about the prospects for success on this project. The FreeDOS roadmap ( http://www.freedos.org/wiki/index.php/FreeDOS_Road_Map ) is out of date and short on details. I would like to see a broad discussion on the roadmap, get consensus and have it updated. Anything that use

Re: [Freedos-devel] Working on FreeDOS 1.2

FDNPKG: I can help you with the changes to FDNPKG to allow it to compile under Open Watcom and to use mTCP. I would certainly like to see more people using mTCP to build their applications. However, is moving to mTCP going to improve FDNPKG enough to make it worth the effort? (That is just some

Re: [Freedos-devel] [Freedos-user] Heads up: "DOS ain't dead" forum is closing

Crisis averted. :-) -Mike Robert Riebisch wrote: >Dear all, > >You have probably noticed, that I have received a lot of public feedback >(plus a few private mails) on my announcement to close this forum. >Thanks for that! I didn't know, that this forum is such an important >part of the DOS com