Just wondering: is it possible that all reported file system corruptions were
for FAT12/FAT16 disks?
Because - as I understand it - the FAT32 disk read mechanism (INT21 AX=7305)
has
protection against the supposed bug, while FAT16 (INT25/26) has not.
Tom
___
> 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.
As a little known fact:
for FreeDOS, "BUFFERS=10" is implemented as "at least 10, or whatever fits
into HIGH memory"
"BUFFERS=-10" means "exact
Hallo Herr Eric Auer via Freedos-devel,
am Dienstag, 5. August 2025 um 02:00 schrieben Sie:
> Hi Tom,
>> cache INVALIDATION is only needed because the BUFFERS cache
>> might have stale data that are not yet on disk.
>> It's a brute force clutch, not a real solution.
> Scary. How about triggeri
Hi Eric,
> thank you for the analysis that int 25/26 disk access
> (and int 21.73 access) bypass the kernel BUFFERS cache.
> Note that int21_fat32 (int 21.7305) would even get
> disk area type flags (dir, fat, data) from the caller,
> which would make it easier to "buffer" those calls.
> I agree
Hi Joe and Bernd,
thanks for the work.
IMHO this is definitively a kernel bug, not a DOSLFN bug. Sure, ResetDrive
works around the bug,
but the bug is still in the kernel.
I think the bug occurs because the (necessary) direct disk writes by DOSLFN,
using INT 25/26,
are not synchronised to the
Hi,
some comments.
First, I find it absolutely remarkable that the combination of FreeDOS kernel
and DOSLFN went without
reported problems for 20+ years. So much for 'testing' by installing ...
>> Am 10.06.2025 um 14:19 schrieb Jerome Shidel via Freedos-devel
>> :
>>
>> When installing the A
Hallo Herr Bob Smith via Freedos-devel,
am Freitag, 30. Mai 2025 um 22:37 schrieben Sie:
> On 5/30/2025 3:14 PM, tom ehlert via Freedos-devel wrote:
>> Bob,
>> >>> It can be loaded from CONFIG.SYS. Perhaps the events you want to trap
>> >>> appear before
Hallo Herr Bernd Böckmann via Freedos-devel,
am Freitag, 30. Mai 2025 um 19:17 schrieben Sie:
> Hi Tom,
>> after all this work, it's time for the EXTKEYB.EXE utility.
>>
>> It's quick and efficient, patent free and listed below
>>
>>
>> #include
>>
>> main()
>> {
>> *(unsigned char fa
Bob,
>> It can be loaded from CONFIG.SYS. Perhaps the events you want to trap appear
>> before CONFIG.SYS is processed, in which case this tool won't help.
>> Otherwise, it can be very helpful.
The events should happen before CONFIG.SYS.
Luckily S-ICE can be loaded before CONFIG.SYS.
Unfortuna
>> after all this work, it's time for the EXTKEYB.EXE utility.
>>
>> It's quick and efficient, patent free and listed below
>>
>>
>> #include
>>
>> main()
>> {
>> *(unsigned char far *)MK_FP(0x40,0x96) |= 0x10;
>> }
>>
>> to be run on buggy machines, before mKEYB runs.
>>
> thanks!
Bob,
> On 5/30/2025 4:58 AM, Bernd Böckmann via Freedos-devel wrote:
>> I finally got my hands on a machine that shows the symptom of BDA 40:96
>> getting changed, and I was able to identify the problem.
>> > When the PC starts, BDA 40:96 is initially zero. As soon as the users
>> > enters some
Hi Bernd,
after all this work, it's time for the EXTKEYB.EXE utility.
It's quick and efficient, patent free and listed below
#include
main()
{
*(unsigned char far *)MK_FP(0x40,0x96) |= 0x10;
}
to be run on buggy machines, before mKEYB runs.
Tom
___
> Hi Eric,
>> new components should NEVER be tested in conjunction with multiple other
>> changes. NEVER.
> A good idea in theory, but upgrading a distro, including FreeDOS,
> usually gives you updates to dozens, hundreds or thousands of
> packages and this is how in practice MANY users "live"
Hi Bernd,
>> Am 27.05.2025 um 16:17 schrieb tom ehlert via Freedos-devel
>> :
>>
>> I don't have any secret information.
>> I'm just worried that there might be a reason PerditionC hasn't released
>> *any* kernels over the last few years, whi
Hi,
> Thanks to all for the attention.
> Actually I seem to vaguely remember some such list in an undocumented DOS
> book or document, but was unable to find it, and hoped someone would.
you might mean the list of error codes for failing function calls,
where "out of disk space", "invalid handle
re is nothing to say against an update of this kernel if
> something goes wrong or is still missing.
>
> Willi
>
>
>
>
>
> Sent: Tuesday, May 27, 2025 at 4:17 PM
> From: "tom ehlert via Freedos-devel"
> To: "Technical discussion and q
Hallo Herr Bernd Böckmann via Freedos-devel,
am Dienstag, 27. Mai 2025 um 11:52 schrieben Sie:
>> Am 27.05.2025 um 09:02 schrieb tom ehlert via Freedos-devel
>> :
>>
>> A new kernel.sys can be - and should be - tested independently of all the
>> surrounding s
Hallo Herr Jerome Shidel via Freedos-devel,
am Dienstag, 27. Mai 2025 um 04:00 schrieben Sie:
> On May 26, 2025, at 6:02 PM, Wilhelm Spiegl via Freedos-devel
> wrote:
> does this mean that the new test kernel is in fdt2506?
> Should be. Unless something doesn’t work the way it is supp
Hallo Herr Jerome Shidel via Freedos-devel,
am Montag, 26. Mai 2025 um 16:52 schrieben Sie:
> Hi Tom,
>> On May 26, 2025, at 10:03 AM, tom ehlert via Freedos-devel
>> wrote:
>>
>> Hallo Herr Jerome Shidel via Freedos-devel,
>>
>> am Montag, 26. Mai
Hallo Herr Jerome Shidel via Freedos-devel,
am Montag, 26. Mai 2025 um 14:49 schrieben Sie:
> Hi Bernd,
>> On May 26, 2025, at 7:12 AM, Bernd Böckmann via Freedos-devel
>> wrote:
>>
>> Hi,
>>
>> for testing I want to update the kernel binaries for the next interim
>> release with builds fr
Idle is a masterclass example why DOS is NOT an operating system.
In a real operating system, there would be ONE method to tell the OS
that "I am currently out of work", not a dozen possibilities to do that.
> Int 28 is vaguely similar, it is the DOS idle interrupt
> called by DOS itself, to gi
Hallo Herr Antony Gordon via Freedos-devel,
am Sonntag, 18. Mai 2025 um 18:25 schrieben Sie:
> There is a DOSIDLE program that I run in VBox (and VMWare Player) in DOS so
> that the VM doesn't run so hard.
> Perhaps if you look at that code, there may be some clues to answer what
> you need. Lin
Hallo Herr Eric Auer via Freedos-devel,
am Montag, 12. Mai 2025 um 02:03 schrieben Sie:
> Hi!
>> i posted the error and a screen shot of it in the kernel issues thing
>> https://github.com/FDOS/kernel/issues/205
> Let me type this screenshot message over and comment on it:
> Immediately after
> Btw, @ tom, msedit is not from MS but from Mateusz Viste, but it is not
> complete.
I have decided on my DOS editor 30 years ago; so I have no opinion in this.
Still interested in what is an editor that "it is not complete." ?
Tom
___
Freedos-d
Hallo Herr Bret Johnson via Freedos-devel,
am Montag, 28. April 2025 um 04:53 schrieben Sie:
>> the resident part of SETVER (MS-DOS 6.22) when loaded as a device
>> driver is 464 byte on my system. This is mainly the version table
>> (4Bh bytes for other stuff like the device header). The SETVER
Hallo Herr Wilhelm Spiegl,
> c) edit: there are so many bugs reported at gitlab (one a small part of it
> see:)
>...
> that it would make sense to create a new editor. But anyhow it works.
And that from a guy who has not the faintest idea how much time it takes
"to create a new editor". Unpai
Hallo Herr Bret Johnson via Freedos-devel,
am Samstag, 26. April 2025 um 01:52 schrieben Sie:
>> I noticed that there is a minimal SETVER driver implementation [1] in the
>> FreeDOS kernel source, and it is shipped with FreeDOS as SETVER.SYS. However,
>> there is no accompanying executable in the
>> Am 16.04.2025 um 21:32 schrieb tom ehlert via Freedos-devel
>> :
>>
>> before you posted "the flag gets cleared even before the first driver is
>> loaded, depending on what gets selected in the FreeDOS
>> boot menu (probably more which
Hallo Herr Bernd Böckmann via Freedos-devel,
am Mittwoch, 16. April 2025 um 14:15 schrieben Sie:
>> Am 14.04.2025 um 23:10 schrieb Bernd Böckmann :
>>
>> I will prepare such a kernel and make it available to Willi, but start with
>> displaying 40:96 right before and after the menu selection, b
Hallo Herr Bernd Böckmann via Freedos-devel,
am Montag, 14. April 2025 um 20:05 schrieben Sie:
>> Am 14.04.2025 um 15:50 schrieb tom ehlert via Freedos-devel
>> :
>>
>> You are saying that this depends on the menu option being 3, independent of
>> the eff
Hallo Herr Bernd Böckmann via Freedos-devel,
am Montag, 14. April 2025 um 21:20 schrieben Sie:
> Hi Eric,
>> Am 14.04.2025 um 21:14 schrieb Eric Auer via Freedos-devel
>> :
>>
>> If I understand you correctly, then JEMM386, but not JEMMEX,
>> clears the ext keyboard flag at 40:96, but should n
Hallo Herr Bernd Böckmann via Freedos-devel,
am Montag, 14. April 2025 um 12:18 schrieben Sie:
> Hi,
> we (Willi Spiegl) have a machine, where depending on the the FreeDOS boot
> menu selection, keys on his german keyboard like {}[] are not recognized.
> I remotely narrowed this down to the ex
Hallo Herr Jerome Shidel via Freedos-devel,
am Donnerstag, 10. April 2025 um 13:45 schrieben Sie:
> Hi All,
> Like many of you, I’ve been checking out various news articles that are
> popping up around the web covering the release of 1.4.
> While many are just re-posts of content written by ot
Hi Bernd,
am Freitag, 21. März 2025 um 15:05 schrieben Sie:
> The index.md [1] of the repo indicates that the XCOPY 1.7 binary is built
> with Open Watcom.
> There reportedly was an issue [2] regarding stack usage with the Open Watcom
> built binaries.
> Skimming over the source, especially [
Hallo Herr Eric Auer via Freedos-devel,
am Sonntag, 23. März 2025 um 19:53 schrieben Sie:
> Hi! If the file is EXACTLY 2 GB then maybe MOVE and XCOPY do
> not support the special file open and seek modes needed to
> support file sizes between 2 GB and almost 4 GB. Jeremy? :-)
The Freedos kernel
Hallo Herr tom ehlert via Freedos-devel,
am Donnerstag, 27. März 2025 um 17:56 schrieben Sie:
> Hallo Herr Fritz Mueller via Freedos-devel,
> am Donnerstag, 27. März 2025 um 17:51 schrieben Sie:
>> thanks, I already tested it, also works fine. so only the copy command is
>
Hallo Herr Paul Dufresne via Freedos-devel,
am Freitag, 28. März 2025 um 12:55 schrieben Sie:
> Remember that dosdef (
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.4/pkg-html/dosdef.html
> ).
> In previous messages, I found that actually, it does go to a blue screen
Hallo Herr Fritz Mueller via Freedos-devel,
am Donnerstag, 27. März 2025 um 17:51 schrieben Sie:
> thanks, I already tested it, also works fine. so only the copy command is
> over for the moment, but I will have to test if it is already fixed or not (i
> already reported anywhere at git that 3
Dear Paul,
it would be really cool if you could stop posting [Off-topic] stuff to this
list.
Thank you.
Tom
am Donnerstag, 27. März 2025 um 06:05 schrieben Sie:
> I change a bit my approach to the AI.
> I added a System Instruction:
> I am an AI that want to translate dosdef.com, a game writ
Hi,
> A new release of move is available which greatly reduces (but does not
> eliminate it) when a stack overflow will occur.
> (moved some variables static reducing used stack during recursion and
> before, also increased default stack size)
> https://github.com/FDOS/move
> https://github.com/F
Hallo Herr Jerome Shidel via Freedos-devel,
am Freitag, 21. März 2025 um 14:14 schrieben Sie:
> Hi Eric,
>> On Mar 21, 2025, at 6:03 AM, Eric Auer via Freedos-devel
>> wrote:
>>
>>
>> Hi! Just guessing, but...
>>
>> Maybe xcopy recursively copies directories? Have you tried to trigger
>>
Hallo Herr Jerome Shidel via Freedos-devel,
am Freitag, 21. März 2025 um 17:12 schrieben Sie:
> I was just sent a test build of xcopy with an increased stack size.
> The Stack Overflow did not occur on the existing filesystem during the copy.
> After adding some deeper sub-directory nesting, t
Hallo Herr Paul Dufresne via Freedos-devel,
am Donnerstag, 20. März 2025 um 06:58 schrieben Sie:
> Not much people responding!
> Maybe I was rude a bit, by not giving a link to specific Ralf Brown interrup
> list function:
> https://www.ctyme.com/intr/rb-1514.htm
you were rude to me by not pro
Hallo Herr Ralf Quint via Freedos-devel,
am Montag, 17. März 2025 um 20:34 schrieben Sie:
> On 3/17/2025 10:58 AM, tom ehlert via Freedos-devel wrote:
>> Hi Ralf,
>>
>> al_findfirst() seems to be implemented by the GCC RTL. This might as well be
>> a bug in this imp
Hi Ralf,
>> bolitare
>> Extra menu/change background
>> double-click BG
>> select a JPG file
>> click select background
>> Sometimes, seldomly, the bug is triggered
>>
>> I checked a bit the source code.
>>
>> Files seems to be read with (in browser.c):
>> void initialize_dir_file()
>> {
>>int
>> Is the task "FreeDOS is an open source operating system. Locate MOVE sources
>> from freedos.org"
>> included in Jims "usability testing" of the website?
For those who found that easy here's the task for advanced users:
"Locate COMMAND.COM sources starting from freedos.org"
BTW: https://f
Hallo Herr Bernd Böckmann via Freedos-devel,
am Dienstag, 4. März 2025 um 01:18 schrieben Sie:
> Hello Tom,
>> Am 04.03.2025 um 00:42 schrieb tom ehlert via Freedos-devel
>> :
>>
>> My suggestion would be to attach these language data to the end of the .exe
>&
>> It could also use some sort of compression people have around anyway, such
>> as GZ or ZIP :-)
> Sure it could use GZ. But that would blow up the code size by a factor of ten
> or more, I guess.
Many times more. There is no *one* ZIP or GZ compression alghorithm; there are
multiple differ
Hallo Willi,
ich habe vermutlich dieser Tage einen
KERNEL.SYS der nicht mehr mehr als 4G Files erzeugt
MOVE.EXE der Files > 2G verschieben kann.
Möchtest du die testen?
Tom
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https:/
Dear Bret,
> I am still trying to develop a good infrastructure in the programs to handle
> multiple languages, though -- one where I wouldn't necessarily need to be
> very involved in the process of adding new languages to a program. KITTEN
> really isn't that useful for me for multiple reaso
Hallo Herr tom ehlert via Freedos-devel,
am Sonntag, 2. März 2025 um 09:46 schrieben Sie:
> Hi everybody,
> just noted that DOSFSCK is missing from
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/.
> Which is sad as CHKDSK doesn't touch FAT32 drives. I
Hallo Herr Bernd Böckmann via Freedos-devel,
am Samstag, 1. März 2025 um 20:40 schrieben Sie:
>> the bug is found, fixed, and was communicated on this list.
>>
>> That this is not implemented in the latest RC3 is a sad shame.
> It is fixed for the FreeDOS package via [1].
>> I'm fairly certain y
Hi everybody,
just noted that DOSFSCK is missing from
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/.
Which is sad as CHKDSK doesn't touch FAT32 drives. I'm not aware of other
chkdsk like programs for FAT32.
Instead I stumbled over this gem of software
https://www.ibiblio.org/pu
Hi Jerome,
>> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/move/
>> is from 2006-08-31 13:53. Is that the most recent move?
> For the binaries, yes.
Is https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/ the "official"
FreeDOS source, and everything else just copies?
Dear Victoria,
am Sonntag, 2. März 2025 um 06:04 schrieben Sie:
> i dont have the compiler of ospimg...
> i tested it with an extended 400k format of a 13cm (5.25) disk which is
> usually standard at 360k
> it is at that format because it was able to be done in FreeDOS
> format.exe
> i cannot se
> I do not think the “out of memory” issue on VMware has had a resolution
> provided.
It does. The solution is to re-enable the exe-header modification of
command.com.
the bug is found, fixed, and was communicated on this list.
That this is not implemented in the latest RC3 is a sad shame.
Hallo Herr Jerome Shidel via Freedos-devel,
am Samstag, 1. März 2025 um 20:22 schrieben Sie:
> Hi Tom,
>> On Mar 1, 2025, at 1:42 PM, tom ehlert via Freedos-devel
>> wrote:
>>
>>> I do not think the “out of memory” issue on VMware has had a resolution
>>
Hi everybody,
on the search for the sources of the most recent MOVE, I encounter a problem:
google places
https://github.com/TritonDataCenter/sdcboot/tree/master/freedos/source
very high in my search results, where somebody uploaded all of freedos sources
to GITHUB 12 years ago,
and never upl
Hallo Herr Bret Johnson via Freedos-devel,
am Freitag, 28. Februar 2025 um 00:52 schrieben Sie:
>> FreeDOS is much more stable then MS-DOS due ot:
>> 1) Eric Auer did a nice job flushing files to disk which lowered considerably
>> power failure problems
>> 2) It is much better then MS-DOS for com
ll II
> Mobile: +1 813-300-2330 <+18133002330>
> VoIP: +1 813-704-0420 <+18137040420>
> Email: segin2...@gmail.com
> LinkedIn: http://www.linkedin.com/pub/kirn-gill/32/49a/9a6
> On Thu, Feb 27, 2025 at 4:03 PM tom ehlert via Freedos-devel <
> freedos-devel@lis
Hallo Herr Alain Mouette via Freedos-devel,
am Donnerstag, 27. Februar 2025 um 21:53 schrieben Sie:
> Em 27/02/2025 13:08, Bret Johnson via Freedos-devel escreveu:
>> I don't know how often you use other versions of DOS (like MS or PC or DR or
>> EDR or ...) compared to FreeDOS, but a TSR woul
Hi,
>> and whatever UPBs and DPBs and lDOS style S MCBs are: can't be that
>> important.
> UPBs (Unit Parameter Blocks) are known to the FreeDOS kernel and the
> interrupt list as DDTs (Drive Data Tables), to EDR-DOS as UDSCs (Unit
> Descriptors), and to MS-DOS as BDS (Block Data Structure).
Hi,
> Recently, ECM submitted a pair updates to the MEM command "fix search_sd
> returning an uninitialised pointer if empty SD MCB”
> and “fix search_sd omitting last SD sub-MCB if it is empty” the FreeDOS
> GitLab Archive. [1]
> As far as I know, there is no upstream project for the MEM comm
Hallo Herr Gregory Pietsch via Freedos-devel,
am Donnerstag, 24. Oktober 2024 um 19:17 schrieben Sie:
> I am sending a GPLed version of the Unix make utility in the hopes that other
> programmers can make it great again! Please send back improvements.
Place it into the next garbage bin.
Tom
Hi,
am Montag, 24. Februar 2025 um 15:59 schrieben Sie:
> I am releasing onto an unsuspecting world a new version of libm, the math
> library of awesomeness.
> What I would like to know is, how close is this to 1.0?
I haven't seen any discussion of it on freedos-devel@lists.sourceforge.net,
Hi Kirn,
am Samstag, 22. Februar 2025 um 00:20 schrieben Sie:
> Due to various complaints of technical issues and bugs that all have the
> same common element of Broadcom virtualization technology ("VMware"), and
> with changes to the hypervisor that have rendered the virtualized
> environment so
Hallo Herr Bernd Böckmann via Freedos-devel,
am Donnerstag, 20. Februar 2025 um 00:11 schrieben Sie:
> Hello Jeremy,
> On 20.02.2025 00:03, perditi...@gmail.com wrote:
>> Thanks for looking into it. I will have a look at Watcom build and > see
>> why it's not patching header.
> Have a look
Hallo Herr Eric Auer via Freedos-devel,
am Freitag, 21. Februar 2025 um 13:20 schrieben Sie:
> Hi Tom,
>>> As you already say, XMS SWAP in FreeCOM already makes DOS
>>> memory footprint very small while apps run,
>> Which is true - because XMS_SWAP
>>> little need to load it high into preciou
Hallo Herr Paul Dufresne via Freedos-devel,
am Donnerstag, 20. Februar 2025 um 11:34 schrieben Sie:
> I realize I tended to wrongly think that HIGH was in EMS or XMS regions (over
> 1 Mb).
> But now I kind of realize that HIGH is really above 640 kb, while still lower
> than 1 MB (default addre
Hi Eric,
> Hi Paul!
Paul as a newbie is excused for his ignorance, Eric as a 'senior' is not.
> As you already say, XMS SWAP in FreeCOM already makes DOS
> memory footprint very small while apps run,
Which is true - because XMS_SWAP
> so there is
> little need to load it high into precious UMB
Hallo Herr Bernd Böckmann via Freedos-devel,
am Mittwoch, 19. Februar 2025 um 21:05 schrieben Sie:
> I agree with Tom that changing the EXE header should be to way to go.
> I did a quick test by patching the COMMAND.COM header by hand with a hex
> editor.
> When I patch offset 0x0A to be 0x400
Hallo Herr Bernd Böckmann via Freedos-devel,
am Mittwoch, 19. Februar 2025 um 12:31 schrieben Sie:
>> Am 19.02.2025 um 09:51 schrieb Bernd Böckmann via Freedos-devel
>> :
>>
>> As previously stated, a significant portion of upper memory is not available
>> under VMware. So we should further t
Hallo Herr perditionc--- via Freedos-devel,
am Dienstag, 18. Februar 2025 um 00:59 schrieben Sie:
> On Mon, Feb 17, 2025, 6:07 PM Victoria Crenshaw via Freedos-devel <
> freedos-devel@lists.sourceforge.net> wrote:
>> I love this for testing!! We should test an newer kernel too lime thr git
>> ve
Hallo Herr Julius Schwartzenberg via Freedos-devel,
am Dienstag, 18. Februar 2025 um 22:32 schrieben Sie:
> Hi all,
> Looking for a tool to automate keyboard presses, I came across this page:
> http://www.retroarchive.org/garbo/pc/keyboard/index.html
> And found this tool:
> stfkey40.zip827
Hallo Herr Louis Santillan via Freedos-devel,
>> http://svardos.org/sved/
I don't care about any DOS editor other then mine, which I have used for
30 years, and I'm not going to change that.
BUT:
the above mentioned SVED shows how to write *really* small programs in WATCOM C.
it provides a mi
Hallo Herr Paul Dufresne via Freedos-devel,
PLONK
Tom
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Hallo Herr Jerome Shidel via Freedos-devel,
am Montag, 17. Februar 2025 um 09:02 schrieben Sie:
>> On Feb 16, 2025, at 5:43 PM, tom ehlert via Freedos-devel
>> wrote:
>>
>> Hallo Herr Jim Hall via Freedos-devel,
>>
>> am Sonntag, 16. Februar 2025
Hallo Herr Jim Hall via Freedos-devel,
am Sonntag, 16. Februar 2025 um 22:20 schrieben Sie:
> I'm bringing back an item we talked about on the video call this morning.
> Folks have discussed a few times on this email list about dropping the
> FDTUI program from the distribution. But FDTUI was al
While we are at it:
Any reason for the inclusion of MINIBOX?
Tom
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
a version 2.0 without
> this features.
I can agree with that. Just not going to happen any time soon.
Tom
>
>
> Sorry, but I think this had to be said.
>
> Willi
>
>
> Sent: Sunday, February 09, 2025 at 4:33 PM
> From: "tom ehlert via Freedos-d
Hallo Herr Fritz Mueller via Freedos-devel,
am Sonntag, 9. Februar 2025 um 13:48 schrieben Sie:
> Hi Eric, hi all,
>
> I am happy to inform you that Nikkho published version 2.0.5 of ZEROFILL.
> It fixed a lot of minor bugs, among others it was unable to write more than 2
> GB with FD and
> It's a port of GNU grep 2.0 (1992). It does not support recursion by
> itself yet (-r). Therefore one would need a real mode port of GNU or
> BSD find, which unfortunately does not seem to be available for FreeDOS.
> Couple options then:
> 1. Add /S support to FDOS FIND;
> 2. Port GNU or B
Hallo Herr Bruno Ribeiro via Freedos-devel,
am Freitag, 7. Februar 2025 um 17:28 schrieben Sie:
> On 7/2/2025 11:00, Eric Auer via Freedos-devel wrote:
>>
What's the DOS equivalent of the Unix find-grep combo for searching
recursively within a directory all files matching a given crite
Hallo Herr Eric Auer via Freedos-devel,
am Freitag, 7. Februar 2025 um 14:54 schrieben Sie:
> However, there
> are people working on the ability to boot DOS from FAT partitions
> (FAT16 or FAT32) on GPT-partitioned disks.
This is completely new to me. Any links to share?
Tom
> Looking for a DOS-centric way of doing that.
The DOS-centric way is not doing that at all.
> As last resort I know I
> can always install DJGPP's find and grep.
exactly.
Tom
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
h
>That's good to know. But why not WASM, for consistency? Perhaps NASM
>has more features, stronger support for macros and/or is better
>maintained? Rules for using one over another? (Like pure vs hybrid
>language packages?)
History. NASM is available for free for much longer time then WASM; so
> Similarly, APPEND has a script make.bat that can be used to build
> APPEND.EXE using NASM assembler that is also available within FreeDOS.
> However, file NOTES of package ASSIGN says:
> Target compilers: Borland C v3.1+; Micro-C v3.13
> And provides MAKEFILE and COMPILE.BAT for building b
> I tested with JEMMEX 5.84 from RC1. Same problem. However, when I boot
> with FreeCOM 0.85a and then launch FreeCOM 0.86 after the system is
> booted, it works.
>> This could be related to the “out of memory” issues Paul Dufresne was
>> experiencing on real hardware with RC1, FreeCOM 0.85a an
Hi,
> Logger is also very fast. While I am sure that you could use a benchmark
> program to see a small reduction in overall command line text output
> performance, you will not notice it is running. Adding RLE would effect
> performance.
I did my own implementation of RLE (feel free to ask f
>> A couple of corrections...
more corrections ;)
>> ...
>>> There is even an EMM286.EXE driver for machines with a 286 CPU floating
>>> around
>>> the Internet that basically does the same thing EMM386 from MS does
>>> (including
>>> providing virtualized EMS).
>>
>> Never seen that one. But
Hallo Herr David Schwab via Freedos-devel,
am Dienstag, 21. Januar 2025 um 23:05 schrieben Sie:
> From memory, XMS was earlier,
time to check your memory. EMS was available for the 8088, and was VERY useful
for a couple of
business programs (like Lotus 1-2-3 r2, Wordperfect, SuperCalc, As Easy
Hallo Herr Liam Proven via Freedos-devel,
am Montag, 20. Januar 2025 um 23:40 schrieben Sie:
> I have a little SvarDOS based project that's getting some interest:
> https://github.com/lproven/usb-dos
> A user and contributor reported that JEMM isn't yielding usable EMS
> and suggested this inst
> The UnRAR source is in a tar.gz file. That contains a license.txt file
> which says: (omitting some extra text at top and bottom of the file)
>> 2. UnRAR source code may be used in any software to handle
>> RAR archives without limitations free of charge, but cannot be
>> used to d
Dear Paul Dufresne via Freedos-devel,
am Donnerstag, 16. Januar 2025 um 16:11 schrieben Sie:
C:\>>logger
C:\>>dns
> Commande ou nom de fichier incorrect - "dns".
C:\>>logger
C:\>>set LANG=en
C:\>>ping google.com
> Resolving `google.com'...No Error
C:\>>ping tunes.org
> Resolving `tunes.org'...No
Hi Jerome,
> 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 pr
> Recording in MONO instead of COLOR will roughly double the capacity. But, it
> won’t look as pretty when simply viewing the log.
recording in COLOR, the color would be an good candidate for compression; even
trivial runlength encoding
would probably provide excellent compression ratio as col
Hallo Herr Eric Auer via Freedos-devel,
am Montag, 13. Januar 2025 um 22:37 schrieben Sie:
> Hi!
> While SvarDOS MORE indeed sounds very basic, SvarDOS TREE
> could be interesting: It seems to be a variant of PD TREE
> which makes it both SMALLER and more multilingual. However,
> it lacks one i
> and I
> think a kernel update that supports WfW should bump up the
> distribution version to FreeDOS "2.0".
I also misunderstood this. As far as I understand it, the (possibly) upcoming
kernel
works with Windows 3.1 in advanced mode. Working with WfW (Windows for
Workgroups)
is unfortunately an
> b) fdtui is a tumbler. I think it is really enough to download it via fnpkg.
+1
Tom
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Hallo Herr Jim Hall via Freedos-devel,
> I'll put
> a note in the news item that it's for testing, so people would need to
> use SYS to try it out on their own.
no need to SYS anything.
It's enough to replace KERNEL.SYS with the new KERNEL.SYS and reboot.
Even dummies should be able to do this.
1 - 100 of 168 matches
Mail list logo
