headers
Bart Oldeman | 22 Mar 2003 05:20
Picon

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.

Bart

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Eric Auer | 20 Mar 2003 01:08
Picon

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


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...

Eric.

PS: For the records: You used Dosemu 1.1.4.13 and the closest
versions to 2026 / 2027 that you tried were 2025c and 2026b.

-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Norman Schmidt Jr | 19 Mar 2003 21:15
Picon

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

  BINGO!
Thank you very much Eric, your tip hit right to the spot!
After two days of testing:
DOSEMU 1.1.4.13 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 1.1.4.15, 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.
Regards,
Norman
(Continue reading)

Permalink | Reply | 0 comments |
headers
Natalia Portillo | 8 Jan 2003 17:20
Picon

OT: Translators

Hi!

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> teleline.es

Regards,
Natalia Portillo
Canary Islands Computer Museum
Permalink | Reply | 0 comments |
headers
Natalia Portillo | 24 Dec 2002 22:56
Picon

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
Permalink | Reply | 0 comments |
headers
Martin Cernohorsky | 14 Nov 2002 13:42
Picon

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?

Thanks,
						cerno

--
Martin Cernohorsky
cerno <at> ics.muni.cz
Permalink | Reply | 0 comments |
headers
Eric Auer | 14 Nov 2002 07:37
Picon

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:
http://www.coli.uni-sb.de/~eric/stuff/soft/specials/ dosdosfsck-2.8.2.zip

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 (http://www.delorie.com/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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Auer | 14 Nov 2002 06:34
Picon

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

Hi,
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!
Permalink | Reply | 0 comments |
headers
Eric Auer | 14 Nov 2002 02:19
Picon

Re: Re: Re: xx-DOS (im)possible problem!


Hi, you compile prntsr simply by doing:
nasm -o prntsr.com prntsr.asm

It does not matter if you use nasm for Linux or nasm for Dos for doing this.
Nasm should be included in FreeDOS, but if you do not have it:
http://nasm.sourceforge.net/
A bin worrying: The TODOs are mostly assigned to nobody, but at least the
nasm/tasm compatibility efforts are active.

Eric
Permalink | Reply | 4 comments |
headers
Steffen Kaiser | 14 Nov 2002 01:24

[ANN] FreeCOM v0.83 Beta 54


Hello,

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 sf.net.

Changelog:
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
#1313]
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]

Bye,

--

Steffen Kaiser

The current maintainer of FreeCOM <at> FreeDOS.org
http://freedos.sourceforge.net/freecom/FreeCOM.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Auer | 14 Nov 2002 00:17
Picon

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:
SCREEN=0x12
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:

http://www.coli.uni-sb.de/~eric/stuff/soft/specials/ vga30.zip

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.

Eric
(Continue reading)

Permalink | Reply | 0 comments |

Gmane