Antony Gordon | 7 Apr 09:30 2010

(no subject)

Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. Learn more.
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
Freedos-devel mailing list
Freedos-devel <at>
Bart Oldeman | 22 Mar 05:20 2003

RE: [fd-dev] Re: Clipper printing problem with FreeDOS: try this...

On Thu, 20 Mar 2003, Eric Auer wrote:

> Hi Norman,
> well, thank YOU. You found the versions of FreeDOS at which
> 1. File locking started to work better (2026) and
> 2. Clipper printing broke (2027).
> This will probably help the kernel experts to figure out WHY
> 1. and 2. did happen, and how to solve 2. - maybe all this
> even helps with figuring out the "Clipper double locking"
> problems...

1. is because file region locking was not implemented at all for
network drives before kernel 2026.
2. I don't know. I've never used Clipper; but try to produce a log using
dosemu -D+dD -o log
using both FreeDOS kernel versions and watch the differences; that might
reveal something.


To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo <at>
More majordomo info at

Norman Schmidt Jr | 19 Mar 21:15 2003

Re: Clipper printing problem with FreeDOS: try this...

Thank you very much Eric, your tip hit right to the spot!
After two days of testing:
DOSEMU with FREEDOS kernels :
2.0.25_16 = clipper printing OK, but DBF locking problems detected 
(corruption a/o crashing)
2.0.25a_16 = clipper printing OK, but DBF locking problems detected 
(corruption a/o crashing)
2.0.25b_16 = clipper printing OK, but DBF locking problems detected 
(corruption a/o crashing)
2.0.25c_16 = clipper printing OK, but DBF locking problems detected 
(corruption a/o crashing)
2.0.26_16 = clipper printing OK, no file locking problems detected
2.0.26a_16 = clipper printing OK, no file locking problems detected
2.0.26b_16 = clipper printing OK, no file locking problems detected
*2.0.27_16 = clipper printing DEAD, dumps to screen, no file locking 
problems detected
*2.0.28_16 = clipper printing DEAD, dumps to screen, no file locking 
problems detected
*2.0.28_16ax = clipper printing DEAD, dumps to screen, no file locking 
problems detected
I still didnt have time to test with the new 2.0.29 kernel (but as far 
as I know 2.0.29 is the "official " 2.0.28ax, correct?) nor with the new 
dosemu, since I believe this is strictly a freedos issue.
Its now clear that the trouble with clipper printing started at 2.0.27. 
Im now back to 2.0.26b, running and printing from various clipper apps 
in a mixed network (samba+win) with no trouble.

Eric Auer escreveu:

>>...printing from clipper apps still dumps all data directly to screen...
>>After reading tons of old posts on mailing lists archives, I got the
>>impression that clipper printing worked seamlessly in older versions of
>>dosemu+freedos, is that true? Im using only last-bleeding-edge versions,
>>but if an old version solves the problem, I will try it.
>I think you should check 1.0.2 and several 1.1.3/4.x versions of
>DOSEMU, and several 2025..2028ax versions of FreeDOS. Obviously,
>trying different FreeDOS versions is easier than trying different
>DOSEMU versions, so you may want to try that first. Finally, you
>said that your current DOSEMU does work with MS / DR DOS kernels,
>so the bug is likely to be caused by FreeDOS.
>You should contact both the FreeDOS and the DOSEMU developers mailing
>lists to ask if others have experienced similar problems before.
>Maybe there is some change in the configuration file processing or
>printer emulation that breaks Clipper printing for you - then adjusting
>the DOSEMU configuration could help.
>I know that all this is much work, but knowing exactly when the bug
>was introduced will make it easier to find the bug. Alternatively,
>you can use the debug log function of DOSEMU and compare the reaction
>to TYPE ... > PRN to the reaction to Clipper printing. This may allow
>you to figure out the bug location without having to try several
>FreeDOS and DOSEMU versions.
>(Norman uses the 1.1 series of DOSEMU and the FreeDOS kernel from
> as far as I know.)
>PS: Feel free to strip the explanation of binary search from this
>mail and forward the rest to both FD-DEV and DOSEMU-DEVEL.

To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo <at>
More majordomo info at

Natalia Portillo | 8 Jan 17:20 2003

OT: Translators


I have a computer museum and I'm searching for some translators of its webpage.
Please if you could help me, contact via iosglpgc <at>

Natalia Portillo
Canary Islands Computer Museum

Natalia Portillo | 24 Dec 22:56 2002

Merry xmas

Hello all there.

Merry christmas and a happy new year from the Canary Islands Computer Museum.

Natalia Portillo
CEO of the Canary Islands Computer Museum

Martin Cernohorsky | 14 Nov 13:42 2002

Problems booting FD

Dear FreeDOS gurus,

I've problems booting FreeDOS Beta8. I've installed it
on a 400MB partition (type 6, BigDOS) formated as Fat32
using BSD's newfs_msdos. Evrerything seems to work, except
I can't boot FreeDOS from harddisk. Booting from CD works.
And yes, I tried sys c: but it doesn't help. When booting,
it says:

 Loading FreeDOS
 BOOT error!

Could you hint me, please?


Martin Cernohorsky
cerno <at>

Eric Auer | 14 Nov 07:37 2002

DOS DOSFSCK 2.8.2 now actually reads raw DOS disks, try and debug...

Hi, as nobody else found the time by now, I have at least a version
of DOSFSCK for DOS that can READ actual disks made available.

Get it at:

You can use upx to:

        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
    164946 ->     56364   34.17%   djgpp2/coff   dosfsck.exe                   

DOSFSCK is 32bit software, compiled with DJGPP ( )
and only runs if you have a 386 or better. Sorry Tom, but you have to turn off
FreeDOS emm386 while running this, for the usual reasons.

I have tested it in Dosemu with both this:

C:\>dosfsck -a -v a:
dosfsck 2.8 (28 Feb 2001)
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
Boot sector contents:
System ID "FreeDOS "
Media byte 0xf0 (5.25" or 3.5" HD floppy)
       512 bytes per logical sector
       512 bytes per cluster
         1 reserved sector
First FAT starts at byte 512 (sector 1)
         2 FATs, 12 bit entries
      4608 bytes per FAT (= 9 sectors)
Root directory starts at byte 9728 (sector 19)
       224 root directory entries
Data area starts at byte 16896 (sector 33)
      2847 data clusters (1457664 bytes)
18 sectors/track, 2 heads
         0 hidden sectors
      2880 sectors total
Reclaiming unconnected clusters.
a:: 69 files, 1533/2847 clusters

(Note the UNIX style arguments, do not get caught by this one:
C:\>dosfsck /?
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
open /?:No such file or directory (ENOENT)

And also, Unix style:
C:\HOME\RAMDISK>dosfsck -a -v diski~6q.bin
dosfsck 2.8 (28 Feb 2001)
dosfsck 2.8, 28 Feb 2001, FAT32, LFN
Boot sector contents:
System ID "FreeDOS "
Media byte 0xf0 (5.25" or 3.5" HD floppy)
       512 bytes per logical sector
(where diski~6q.bin is the image file that simulates a: ...)

If you select a DRIVE which has at least number C:, then this
DOSFSCK version will always use the > 32 MB access method for
now, probably a bit of a kludge.

Finally, I tried with one of those special compact diskimages
which simulates an 8.5 MB FAT12 harddisk in my Dosemu: Generally,
dosfsck works, but it gets so much confused over some orphaned
LFN chunks that it crashes after a few of them :-(. This does
not happen with the Linux version, I wonder where the problem
actually is, please help with debugging!

DOSFSCK in the Linux version is part of DOSFSTOOLS (mkfs and
dosfsck, or in other words, format and chkdsk). My port is based
on version 2.8, current maintainer is Roman Hodek,
Roman.Hodek <at>
Primary-site: /pub/Linux/LOCAL/dosfstools

DOSFSCK is capable to analyze FAT12, FAT16 and FAT32 partitions and
is pretty fast, but eats pretty much of your RAM (possibly several

The driver that I have added was clearly simpler than expected, but
one of the reasons is that I did NOT write a disk WRITING driver yet.
So DOSFSCK for DOS currently can read and write diskimage files, but
real partitions it can only read. Further limitation is that the
interface for > 2 GB FAT32 partition access is not yet implemented
(see the inside the dosfsck*.zip for some sketchy things,
basically a minimal cut and paste from DISKLIB, concerning FAT32...).

The good point is that you can hardly break anything that way (having
only readonly access in raw disk mode)...

Please help with some testing and bug-hunting.

Here again some typical command line options:
DOSFSCK -r -V a:
  checks a:, prompts you for decisions when needed for repairs, and
  first collects all writes in a simulation buffer, scans a: again with
  the simulation active, and only then asks you if it should write changes.
DOSFSCK -a -v a:
  checks a: with verbose output and does decisions itself.
DOSFSCK -a -t -v a:
  checks a: and does a surface scan as well
DOSFSCK -a -v floppy.bin
  same as above but with a diskimage instead of a real floppy. THIS TIME,
  dosfsck will be able to MODIFY the floppy.bin file, while in all other
  cases, you just get an "a: would have been written now" message for now.

Read the documentation for more information. DOSFSCK can also undelete and
drop single files and can convert lost chains into files. Another new
feature is Atari format mode, to scan Atari disks (strange idea :-)).

Basically, all features are due to Werner Almesberger and Roman Hodek.
I have only done some adjustments to make it compile with DJGPP (luckily,
DJGPP feels very Unix, so adjustments are small) to create what I had
called version 2.8.1 for DOS, and now added the raw disk read driver to
create what I now call version 2.8.2 for DOS. As I did not get feedback
on 2.8.1, I cannot tell you if the crashing of the DOS version is due to
some recent changes in 2.8.2 or "no news at all". Seems to be keyboard /
stack related, I think, but -a mode crashes sometimes, too. Please help
with hunting bugs.

Have fun with this one... Eric.


Eric Auer | 14 Nov 06:34 2002

HMA consumption of _32 (FAT32) vs _16 kernels, normal vs 186/286/386

I have just asked Bart what the diffs between the _32 (FAT32 enabled)
and _16 (normal) kernels would be. He mails: Both are suitable for 8086
(if you want optimized for 186/286/386, you must compile yourself) and
differ mainly in their HMA memory consumption:

The rest is a quote from Bart:

      FAT16 FAT32
 8086 40304 43869
80186 39583 43147
80386 39257 42714

cost of FAT32: 3565--3564--3457 bytes
savings for 386: 1047/1155 bytes

as a comparison I also figured out MSDOS and DRDOS usage a while ago:
DR 7.03 35424 bytes
MS 6.22 37808 bytes

FreeDOS used to be much more memory consuming (2022b2 when I started,
FAT16, Turbo C 2.01, 0xe423 == 58403 bytes) -- getting closer!

Steffen Kaiser | 14 Nov 01:24 2002

[ANN] FreeCOM v0.83 Beta 54


FreeCOM version 0.83 Beta 54 is out.

It includes several minor fixes that should make life easier.
Besides the usual places, there is a File Release in

v0.83 Beta 54:
bugfix: prevent from executing non-*.bat/com/exe files [part 1) BugID #966]
bugfix: calling an external program: preserve leading spaces [BugID #752]
bugfix: ECHO: preserve leading spaces [BugID #1081]

v0.83 Beta 52:
add: CHCP (disabled by default)
bugfix: COPY: additional output to honor redirection {Eric Auer} [bugID
bugfix: onOffStr(): zaps trailing argument delimiters, e.g. ECHO set=
add: save/restore session (swap context) {Tom Ehlert}
bugfix: CTTY CON -> missing CR's {Eric Auer} [bugID #1441]



Steffen Kaiser

The current maintainer of FreeCOM <at>
Eric Auer | 14 Nov 00:17 2002

25, 28, 30, 43 and 50 line text modes in DOS

Hi, you may remember me saying:
ZENO is useless for FreeDOS, FreeDOS already uses fast BIOS TTY.
For TURBO3 holds the same. NANSI will, however, speed up your DOS
screen output even with FreeDOS :-).
So what next? Have more lines of text on the screen, for more scrolling
before scrolling away (by the way, which "backscroll buffer" drivers do
you usually use to scroll back to stuff that would normally have scrolled
away already?)...

I just have this in my fdconfig.sys:
ECHO 8x8 font (0x12) gives us 50 lines of text :-)

Other options are 0x11 and 0x14, for 25 and 28 lines. If you have
EGA, you get 21, 25 and 43 instead of 25, 28 and 50 lines. But for
a special bonus, have my 30 line VGA mode. Not too big, not too small:

This is no TSR, it will just turn your screen into that mode. As soon
as some program resets the screen mode to 25 or 50 lines, you will
probably want to run VGA30 again. This is derived from my readings of
the Linux kernel sources. Have fun!

PS: Should not damage anything, but if your screen starts to smoke,
better reset to get back to 80x25... But is as far as I know a very
ordinary 31.25kHz mode that all screens should show fine.


Natasha Portillo | 13 Nov 23:29 2002

Unified Help System


I saw that all developers for FreeDOS programs uses their own help
system and/or help text file scheme...

I think that is a must for all developers to a standard system, as all
UNIX systems uses man.