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

Just to be very clear; I know we need FDNet. I was just kind of surprised when I looked at it. Given that it has a part of mTCP as a dependency I expected it to install mTCP, or at least only include the parts of mTCP that it needs. I didn't expect it to include the entire source code and develo

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

Hi Jerome, I know you are following ... ;-0 Please hold off on updating FreeDOS with this mTCP. It works but there are some small bugs that are bothering me and some error messages that I want to improve, so I'm going to update it again. I'd rather FreeDOS ship with the previous version (Oct 202

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