I wonder about those creation time set removals. It looks like your
I will consider reverting it, but a config.sys option is overkill.
Yes, it is. It'll be difficult to revert it as it leaded to numerous other
optimisations. Besides, I already explained why I removed it. Why add back
an useless
BTW, Lucho, if you wish, I may prepare for you macroses in TASM to ease
writing more readable and safer country.asm. Probably, someone then may
translate these macro to NASM?
Such translation will be very difficult if not impossible because NASM is
too incompatible :-( So, don't bother with it.
Hola Eduardo,
Not really. In the worst case, only the 4 bytes for the empty DBCS table
will be unused. The idea is to overwrite the hardcoded tables for
CTYINFO, UCASE, FCHAR, and COLLATE and allocate new memory (if needed)
for FUCASE, LCASE and DBCS _only_.
What about a combination of your (1)
The question is: does anyone know what does MS-DOS do?
What now unstable FreeDOS does - ZERO creation time/date and access date
on each directory entry write. Verified.
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
#include fcntl.h
#include io.h
#include dos.h
int main(void)
{
int fd = open(fool.dat, O_WRONLY|O_CREAT|O_TRUNC);
write(fd, hello, 5);
close(fd);
sleep(2);
fd = open(fool.dat, O_WRONLY);
write(fd, hello bye, 9);
close(fd);
return 0;
}
Thanks, Bart. Seems that as I already have
In addition, the MS-ish interface allows revert to real version
number by passing a value of zero.
RBIL doesn't says this.
It does say this. D-2F122F says: DX = DOS version number (h = return
true DOS version). RBIL also says this is supported by Matthias Paul's
FREEVER.COM. Do you see now
Although I dislike the idea of patching the bootsector, choice 2 does
seem most compatible and is slightly smaller boot code (as the logic is
moved to sys).
I agree and prefer method 2 too. The distance between this new patched
boot sector offset and the existing boot segment offset seems
Hallo Bart,
merge in some changes from UNSTABLE
If Bart doesn't like some changes, I don't mind if they're not merged them
into stable ;-)
I wonder about those creation time set removals. It looks like your
removing a useful feature here. Sure a reason given is MSDOS 7.10
doesn't do this.
Eduardo, couldn't we divide the work between ourselves? If you do the
changes in nls_hc.asm for the third option you offered (make enough room),
I will add the necessary code in config.c ;-)
---
This SF.Net email is sponsored by: YOU BE THE
Do you mean
http://www.mail-archive.com/[EMAIL PROTECTED]/msg01070.html
yes
(It doesn't contain other comments but those in the patch.) If you
confirm, I can apply it.
yes.
Just applied and committed (and updated binary on my site ;-)
---
This
Hello,
Award BIOS dated 1999 for Intel i810, and the original IBM PC/AT BIOS
don't seem to pass anything in DL on Int 19h. How did I verify it? For
those who can't guess, let this be my little secret ;-G
(Table 00653)
Values Bootstrap loader is called with (IBM BIOS):
CS:IP = h:7C00h
DH =
The BIOS Boot specification warns that only 0 and 80h can be [...]
[...] interesting enough... Nevertheless, trying it gives me 404...
Moved -
http://www.phoenix.com/NR/rdonlyres/56E38DE2-3E6F-4743-835F-B4A53726ABED/0/specsbbs101.pdf
---
This
Ie., second disk was enumerated as 80h (and, for example, partitions
from it was labeled earlier, than from first disk)?
Yes, exactly.
This warning may be only because authors of tose spec may know about
existance of buggy BIOSes.
No, they state several times that ONLY 0 AND 80 may be boot
Hola Eduardo,
I don't mind adding the changes to nls_hc.asm, but I'm not sure that I
like that option.
Neither do I like it very much, but (1) and (3) are most straightforward
and easiest to implement.
In a private mail, Eric suggested a fourth option: Check if there is
enough room for loading
No, they state several times that ONLY 0 AND 80 may be boot drives.
Ok. What about boot managers?
The option mentioned below is for boot managers too.
For this, an option of SYS will revert back to DL = boot drive
Hm. Your arguments sounds reasonable. But I continue to _feel_, that
using BIOS
I don't understand this. SYS writes 0/FF only into its own images,
builtin into SYS executables. And, if _after_ SYS someone will change
boot loader, then 0/FF value also will be replaced. Where is trouble?
The trouble is that most SYSes don't bother to set this value - they just
copy the whole
Hallo Eric,
we already do have 622k low DOS RAM free in a quite straightforward
configuration (in DOSEMU, where HIMEM / EMM386 take almost no memory,
even 627k), and I never met any program which really needed more than
590k, so this is only about bragging.
Exactly. I have 629 KB free in
Hallo,
Therefore I vote for a SYS option which lets you decide whether or not
the 0x80 in the boot sector will be used. The DEFAULT should be, in my
opinion, to accept the value from the boot manager / MBR / BIOS for
harddisks. For floppy, 0 will be in the boot sector, and the DEFAULT
should
unsigned char check_handle_break(struct dhdr FAR **pdev)
{
- unsigned char c;
+ unsigned char c = 0;
if (ctrl_break_pressed() ||
(c = (unsigned char)ndread(syscon)) == CTL_C
||
*pdev != syscon (c = (unsigned char)ndread(pdev))== CTL_C)
{
Tom, the PRF.C test for %p (far pointers) fails for both kernel branches
(shows just 5678 instead of 1234:5678). I think that you've written most
of the code there, so could you please take a closer look - what could be
wrong with it? Thank you...
Hi again, Justin!
In FreeDOS 2035a, NSSI crashed.
In the newest unstable kernel, NSSI works excellent!
Get NSSI at http://www.navsoft.cz
Thanks for the information! Unfortunately if UDMA or CD-ROM driver is
loaded, it hangs at the checking memory for viruses stage under the
unstable CVS kernel.
If I right remember, Lucho's patch affect os_major and os_minor.
No, it affects os_setver_m??or.
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who
#pragma aux default parm [ax dx cx] modify [ax dx es fs]
Thanks, Eduardo - Jeremy already noted these errors on CPU 386 this and
today I fixed it in the CVS by applying it only for an 80386. The pragma
was suggested by Bart. I don't understand how it works but it does
decrease kernel size
Bom dia, Alain!
Now the kernel no longer removes or renames the current directory of
the drive for which this is requested.
This says that it does not do what is requested... Could you please
rewrite or explain it?
MS-DOS never removes or renames the current directory of the drive for
which
CVS already updated. Binary at
And question again: how to download this lates image?
http://linux.tu-varna.acad.bg/~lig/freedos/kernel/KERNEL.SYS
http://linux.tu-varna.acad.bg/~lig/freedos/kernel/SYS.COM
The boot code in SYS now has the DMA 64K boundary cross bug fix (thanks,
Jeremy! :)
+%BASE%\binw\ms2wlink %1 %2 %3 %4 %5 %6 %7 %8 %9 kernel.lnk
If you have a better fix, I will gladly change it.
Microsoft LINK accepts a trailing colon (;) after the last meaningful
argument instead of commas. Perhaps this would work for MS2WLINK too? Like
this:
+%BASE%\binw\ms2wlink %1 %2
Microsoft LINK accepts a trailing colon (;) after the last meaningful
argument instead of commas
Sorry about my bad English. The dictionary says that the ; sign is
called semicolon, not colon!
---
This SF.Net email is sponsored by BEA Weblogic
Michael, the KAVDOS32 problem is in its Zurenava DOS extender (Russian, of
course ;-) Bind any 32-bit DOS executable with it and it'll hang on exit
under FreeDOS and cleanly exit under MS-DOS. Zurenava source and binary
code are available in a ZIP archive at http://dx.zr.spb.ru/zrdx047.zip
Eric, why don't you fill in a Bugzilla entry with this problem?
Lucho
Tue, 31 Aug 2004 18:53:29 +0200 (MEST), Eric Auer [EMAIL PROTECTED]:
Hi all, please check:
http://www.coli.uni-sb.de/~eric/comdrive-analysis.txt.gz
... and tell me how to make (either by fixing FreeDOS or comdrive or
both) this
it doesn't compile.
Sorry - it turned out that my patches were against a mixture of stable and
unstable branch! Now I got the real unstable CVS sources, cleaned up mine,
and the resulting patch became larger, because it contains some Arkady
changes not in unstable CVS yet. Just uploaded it on
the TU-Varna FTP server has currently some [space?] problems and I can't
upload the files there
Problems got fixed so I uploaded both the patches and the binary there.
You probably know the URL:
http://linux.tu-varna.acad.bg/~lig/freedos/kernel/
One more note: PLEASE don't link to it from pages
Mon, 23 Aug 2004 00:00:30 +1200 (NZST), Bart Oldeman
[EMAIL PROTECTED]:
63978 bytes!!! HOORAY!!! ;-) ;-) ;-)
Still strange. I get 64266, doesn't matter whether it's OW 1.2 or 1.3.
Strange indeed.
#if !defined(FORSYS)
#pragma aux default parm [ax dx cx] modify [ax dx es fs]
#endif
in portab.h
Ciao, Eduardo,
We strive for MS-DOS compatibility, and MS-DOS, PC-DOS, PTS-DOS, OS/2,
Windows 9x and Windows NT all use the same format that is so well
described in the RBIL tables 2619-2622. So I chose that.
IMHO, the COUNTRY.SYS format does not affect compatibility, as the
information is
Hallo Bart,
Yes that's what I meant. What are the errors dsk.c gives you?
None! :-O Don't know why, but now when I edited the UTILS\MAKEFILE to
define EXEFLAT for EXEFLAT.C so that the pragma doesn't affect it,
OpenWatcom 1.3 *successfully* built the kernel and the size is... guess
what -
Lucho, whatever you do. Please leave that copyright message in. You made
a proposal to change it. Then just removed it. Which is worse.
The justice finally caught the criminal! I didn't remove it, I had just
*moved* it to AUTOEXEC.BAT where it can be enjoyed in its full glory for
as long as you
Bom dia, Alain!
I believe that being hated as much as a certain man is a matter of
behaviour.
I always use this analogy: Oracle's product are very expensive, but
their custumers are content and Oracle is not hated at all.
M$ make we feel bad, not because they charge, but because they force us
Now I discovered this using DISKEDIT. It's a double word at offset 488
(1E8h) of the second sector of the FAT32 boot record (which consists of
three sectors, not one as for FAT12 and FAT16). But actually this is
described in
http://www.microsoft.com/hwdev/download/hardware/fatgen103.pdf
It's
It's declared in hdr/xstructs.h as xdpbforformat.setdpbcounts.nfreeclst
but I don't see it updated anywhere! I suppose that this should be done
at the end of kernel/fattab.c:link_fat() along with the update of the
dpbp-dpb_xnfreeclst, but how to do it?
I was wrong. It's fsinfo.fi_nfreeclst and
(some) big corporations _do_ thefting. For example, Sony theft Walkman
idea (AFAIR, from Bulgarian inventor), Logitech was reject co-operation
with Russian developers, but then (quietly) reuse their ideas in own
mice. :(
I didn't know those things, and they only support my anti-corporate
About country sys: Do NOT copy it from another DOS.
It's NOT copied! See COUNTRY.ASM in
http://linux.tu-varna.acad.bg/~lig/freedos/kernel/CVSPATCH.TXT
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R
Hallo Bart,
resolve rejects in exeflat.c :(
Sorry, my fault. Just fixed that and uploaded a new CVSPATCH.TXT,
including a SYS fix - OpenWatcom 1.3 now complains about missing return
type of fat32readwrite so I addeed an int at both places.
I've uploaded it to
63978 bytes!!! HOORAY!!! ;-) ;-) ;-)
I'm looking forward to say Goodbye, Borland! Welcome, Watcom! ;-)
Sadly, I can't do this yet - UPX compressed it to 41604 bytes as COM and
41614 bytes as EXE. aPack - to 42071 bytes as COM. In contrast, the
cowardly Borland 4.0 FAT32/80386 aPacked
UPX compressed it to 41604 bytes as COM and 41614 bytes as EXE.
I mean as SYS, not as EXE. I just changed the first 4 bytes to FF to fake
it.
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for
Hello,
I had forgotten to rename the FAT and CPU variables to XFAT and XCPU,
so what I was getting was a 8086 kernel!
Hm. How you miss kbc8632 instead kbc38632?
No, the Borland configuration file was correct, the problem was with my
other configuration files!
OpenWatcom 1.3, the uncompressed
Hello,
All that MS does - enclose _public_ information into own file format.
What is permitted for Zeus, is not permitted for mortals! :-( That's
exactly what I meant when I wrote that Microsoft are the biggest thefts.
Even their first Basic interpreter was from public domain sources. Not
Hello,
I noticed that I often get CHKDSK/SCANDISK errors that my FAT32 freespace
count is incorrect. This happens when I write new files onto my disk, e.g.
free space decreases. I see that dpb_xnfreeclust is incremented /
decremented in fattab.c:link_fat() but is this the only place where it
Hello,
At http://linux.tu-varna.acad.bg/~lig/freedos/kernel/ are a kernel patch
collection (CVSPATCH.TXT) and binaries (KERNEL.SYS and COUNTRY.SYS) that
add COUNTRY.SYS file support to the kernel and move the hard-coded country
data from the kernel where it belongs - to a separate COUNTRY.SYS
Hallo Bart,
Well if I claim I can get it under 64K I'm not lying.
Did I say you're lying?
OW compiles *plain 2035* as 66318 bytes uncompressed for me for
FAT32/386. Why your kernel is bigger after all these optimizations is a
puzzle. I've read that on low memory machines its optimizer may be
Hallo Bart and Tom,
In this case, instead of pursuing a technical solution (Open Watcom is
open source so can be changed) to reach a certain goal, you suggest I go
for an illegal black-box solution, the cowards' way out.
All right, I was a fly, now I'm a coward. Very well. Perhaps I'm something
Did you run guest to load the drivers for the parallel port Zip Drive?
Yes, and it worked for me.
I tried it three months ago and I could not get it to work. Kernel
version is 2.1.34.
I had composed a simple batch file (LOADZIP.BAT) to replace GUEST and
consume less memory. It's dated 2 May 2004
Hallo Bart,
Question is how much of a difference can you tolerate? From you I get
the impression that a 100K uncompressed kernel that compresses to 3
bytes would be preferable to a 64K one that compresses to 4 bytes.
;-) I could never use an uncompressed kernel that is below 64 KB.
Hallo Tom,
It's not worth a penny because it can be freely downloaded from Vietnam
(I posted the URL here ;-)
I know bulgarians think that way.
Not only Bulgarians. 3/4 of the world thinks so. And many Americans and
Germans too, by the way.
It's still theft.
It would be a theft if I *move* the
interesting loading option, I have SCSI internal zip100 iomega drive.
Does DEVLOAD 3.13 also work for you instead of DYNALOAD?
(no idea if we have put it online somewhere, though :( )
I haven't tried it, but there is no reason why it shouldn't work.
Hello,
First, I'd like to express my gratitude to Alain Mouette for his generous
donation of an external 100 MB parallel ZIP drive + disks to me which
allowed me to catch the bug below. Thank you, Alain!
Attached is the file CVSPATCH.TXT - a cumulative patch for the unstable
branch that
4 days ago, I wrote:
I see! OK, when I copied it from W98 to C:\HX, PESTUB patched MASM 6.15
successfully, so I can now run it in FreeDOS, this time perfectly, also
when building real projects with NMAKE and assembling multiple files at
once. Congratulations! However, when I apply PESTUB to
Hallo Bart,
whatever, now we have 2035, 2.0.35, 1.1.35, and 0.0.35 all as version
numbers ;)
...and 2035, 2035a (why not rename them to STABLE?) and 2035a-UNSTABLE
releases ;)
Just have to send Ralf Brown another email as my previous mod to
interrupt.f will be obsolete.
...in the hope that the
Hallo Bart,
We'll make a deal. If Borland fixes their bug in 32RTM as part of open
sourcing their old 16bit targetting compiler (even lower than the chance
that RBIL will be updated) I'll go for it ;)
And this means - never, and you know it! ;-)
I do recognize other compilers but...
Glad to hear
Hello Michael,
I don't want to suggest basic things you've probably already thought of,
but want to point out that the actual exception due to REP MOVSW in
protected mode is significant. It's not a crash within FreeDOS or
failure within the real mode INT 21h handler. Looks like a bad pointer
Thank you very much, Michael, for your discovery of the 32RTM bug!
There you have it folks. A dumb bug in a Borland product that by purest
happenstance fails under FreeDOS and not MS-DOS. I don't have any idea
how to gracefully fix the problem other than to have FreeDOS change its
serial
FreeDOS kernel build 2035a-WHATEVER. Copyright...
This kernel comes with ABSOLUTELY NO WARRANTY and you are welcome to
redistribute it under certain conditions; press F1 for details.
I'd prefer this:
FreeDOS kernel build 2035a-UNSTABLE Copyleft 1995-2004 Pasquale J.
Villani and
the FreeDOS
Hallo Eric,
Even 2035z would still mean a sufficiently small CX value and 32RTM
would work.
If CX is nonzero, 32RTM will *not* work. And CX *is* zero in *all* DOS
version I've tested (MS-DOS, PC-DOS, ROM-DOS and DR-DOS). Michael, Tom and
Alain are right. There's nothing else we could do but
Hello Japheth, and thanks for your reply!
I downloaded all the 10 ZIPs there but none contained CRTDLL.DLL
Yes. That is because CRTDLL.DLL is copyright MS and is included in every
windows OS.
I see! OK, when I copied it from W98 to C:\HX, PESTUB patched MASM 6.15
successfully, so I can now run
Using the -X option bypasses the InDOS function call, so you don't see a
problem when you use that 32RTM option.
But the InDOS call just does:
case 0x34:
lr.ES = FP_SEG(InDOS);
lr.BX = FP_SEG(InDOS);
break;
What could be wrong here?
The InDOS flag value itself?
Stack
Hello Michael,
Last not least, since it modifies the SFTs, the HiNTOS DOS extender (or
Windows to DOS converter) doesn't work at all in FreeDOS.
This is either a really obscure extender or else also known under a
different name, as even Google Usenet search doesn't pick up a hint of
it. But it
dos_crit_sect:
mov [_Int21AX],ax ; needed!
pushax ; This must be here!!!
mov ah,82h ; re-enrty sake before disk
stack
int 2ah ; Calling Server Hook!
Hello Michael,
More specifically, I would need download access to an application which
fails when running under these (or any) extenders, rather than the bare
extender itself.
The whole Borland C++ 5.02 is in Vietnam at
http://www.saigontech.net/users/htliem/BC502/
The only files you need from
Hallo Bart,
if the partition table loops (recursive problem), MSDOS just hangs but
FreeDOS checks for it and happily uses the partitions that are fine.
Of course, there are bugs in MS-DOS that are not present in FreeDOS. But I
think that the main problem of the FreeDOS kernel are not bugs, but
Hello!
Isn't the real bootable partition always assigned to C:?
BTW, I think this (slightly) misleading, when (boot) partition from
secondary disk becomes C:. Again, I suggest, probably, better to _not_
make it C:, but in main.c:FreeDOSmain() make it
default (to allow process (fd)config.sys from
Hallo Tom,
I have an idea - why not call the UNSTABLE branch DANGEROUS (but still
moving!) and STABLE branch - ROCK-SOLID (like a stone, but also static and
even almost dead as stone ;-) Joking of course...
that you use it doesn't mean there are no news bugs.
e.q. the complete ioctl was 100%
Hallo Tom,
I certainly didn't wait to say this until he's absent
Sure. The eternal dispute continues forever! ;-)
one reason for different behaviour *might* be that smartdrv traps
int25/int26, which is used differently in FreeDOS (not everything is
rooted through it)
What isn't routed through
Hallo Tom,
the kernel talks directly to int13 and never uses int25 internally.
SmartDrive 4/5 doesn't hook Int 25h as SmartDrive 3 hooks Int 13h. Here's
a detailed description of the working principles of SmartDrive 4 and 5 -
http://support.microsoft.com/?id=83325
I don't see any new features
Hello!
Jeremy:
as for patch starting this discussion, I'll look at it when I get home
from work tommorrow afternoon; anyway I've got to get ready
Thanks for your commitment to maintain the kernel now when it's branched
and thus hard to maintain
Aitor:
Could you please fill bugzilla entries with
Hallo Bart,
Honestly I believe you're right here -- the issue is that changing
copyright messages without agreement of the original author is a bit
shaky IMHO. If you just get Pat's go ahead for the change then I'm all
for it.
OK. If Pat reads this list, perhaps he can write here if he approves
Borland 32RTM 1.5 fails to work in FreeDOS but works in MS-DOS.
Forgot the message: Unhandled exception 000D at 0020 034B ErrCode .
This happens without EMM386. I haven't tried it with EMM386 in FreeDOS.
---
This SF.Net email is sponsored by
Hallo Eric,
could you file the list of problems which are mentioned in this thread
as Bugzilla entries?
I already filled in all the 5 bugs (3 kernel and 2 SYS bugs) I reported
but the DOS extender bugs.
I believe some RTM did work - and Lucho found a very small binary patch
to fix 32RTM - so
exeflat.c of build 2035a (not 2035) has a problem. The start segment is an
argument so it's a variable and its value - 2 must be loaded into DI
instead of the constant 0x5E. Here's a fix:
--- cvs\kernel\utils\exeflat.c 2004-07-09 04:16:30.0 +0200
+++ src\kernel\utils\exeflat.c
Hallo Bart,
This is against exeflat.c of 2035a-UNSTABLE. Neither 2035a (i.e. CVS
HEAD) nor 2035 have this problem.
I didn't know that there are TWO kernel builds called 2035a... Perhaps you
should call yours 2035b where b = Bart (a = Arkady ;-)
Regards,
Lucho
Hallo Bart,
#define BUILD 2035
#define SUB_BUILD a
#define KERNEL_VERSION_STRING 1.1.35 /*#REVISION_MAJOR .
#REVISION_MINOR . #REVISION_SEQ */
#define KERNEL_BUILD_STRING 2035a /*#BUILD SUB_BUILD */
#define BUILD 2035a
#define SUB_BUILD -UNSTABLE
#define
Hello Bart,
Actually a couple of years ago it was build 1937 for version 1.0.2 ;)
Wow! Well, I hope that it can be 2.0.60 for build 2060 in just a couple of
years ;-)
nor removal of phrases like All Rights Reserved. that are useless now
Pat sent an email to this list -- here's your chance if you
Hello Tom et al,
or call the 'optimized' kernel keUNSTABLExxx or keARxxx, as the main
stream kernel should concentrate on FIXING bugs, rather then introducing
new ones.
100% agreed. Since I use unstable kernel every day in practice, I think
it has no more bugs than the stable one. But during
On Mon, 05 Apr 2004 20:11:05 +0200, Erwin Veermans wrote:
As always, a patched CVS kernel binary (FAT32, 80386, BC 4.52, aPack)
is available in my ROMDSK binary package that can be downloaded at
http://linux.tu-varna.acad.bg/~lig/romdsk/romd-bin.rar
I get:
Forbidden
You don't have permission
On Mon, 5 Apr 2004 23:13:16 +0100 (BST), Bart Oldeman wrote:
Hi, in the FAQ, somebody claims that file handle 4 should default to
PRN:
http://fd-doc.sourceforge.net/faq/cgi-bin/viewfaq.cgi?faq=incoming/224
Any idea why this would work at all? And why it works in MS but not in
FreeDOS? Used
Hi, in the FAQ, somebody claims that file handle 4 should default to PRN:
http://fd-doc.sourceforge.net/faq/cgi-bin/viewfaq.cgi?faq=incoming/224
Any idea why this would work at all? And why it works in MS but not in
FreeDOS? Used language is C.
Look at the definitions in stdio.h - stdaux is
MS-DOS: CON, AUX, PRN, CLOCK$, A:-D:, COM1, LPT1, LPT2, LPT3, CONFIG$,
COM2, COM3, COM4
FreeDOS: CON, PRN, AUX, LPT1, LPT2, COM1, COM2, COM3, COM4, CLOCK$, A:-D:
Fortunately, fixing this is very easy. It's enough to swap the
corresponding entries in io.asm. Do I need to provide a patch for
Fortunately, fixing this is very easy. It's enough to swap the
corresponding entries in io.asm. Do I need to provide a patch for this?
Here it is, below. Now stdaux and stdprn should work as in MS-DOS.
As always, a patched CVS kernel binary (FAT32, 80386, BC 4.52, aPack) is
available in my
On Mon, 29 Mar 2004 18:55:44 -0300, Alain wrote:
New Power supplies are very cheap. For that they have simplified many
important circuits. They don't handle current fluctuations vary well.
Well, again from bad to worse... They must come with a BIG red sign HLT
forbidden! then :-(
Lucho
On Mon, 29 Mar 2004 19:00:54 -0300, Alain wrote:
INHO and considering that FreeDOS is in C versus all other DOSes being
in ASM
ROM-DOS, our greatest living competitor (not speaking of the venerable
DR-DOS that is still in coma and PC-DOS that must have finally died in
2002) is also written 90%
On Fri, 26 Mar 2004 22:22:20 + (GMT), Bart Oldeman wrote:
Can you check again? I think I solved at least Lucho's problem during the
init phase -- when fnodes could overlap disk buffers! Weird things could
happen indeed.
Congratulations, Bart! Bug fixed indeed - just tried. But I keep thinking
On Sat, 27 Mar 2004 03:22:59 +0300 (MSK), Arkady V.Belousov wrote:
PS: Just checked TechHelp: it says nothing about AL, only AH=6C.
Definitely bug in RBIL. :(
MS-DOS technical reference defines AL=0 as reserved
(http://www.clipx.net/ng/dos5/ng1ff99.php). We already discussed this
issue last
if (new_diroff == 65535)
Borland C++ complains here. Change the constant to 65535UL (see patch
below).
Although Borland says constant is long, it's enough to change it to
65535U, not UL.
Lucho
diff -ruN cvs/kernel/kernel/fatdir.c src/kernel/kernel/fatdir.c
--- cvs/kernel/kernel/fatdir.c
Bart, unfortunately your very last change (scaling and shortening the
directory entry pointer) introduced a bug! When I start my elvis
editor (a vi clone) and exit it, it can't delete its temporary file
ELV_3E5.1 from my XMSDSK RAM disk where is my temporary directory.
4DOS fails to delete it
But what if it was the first entry in the root directory? Then the
new_diroff++ in dir_read() will make it -1!
remove_lfn_entries() checks for fnp-f_diroff == 0. The first entry can't
have any LFN entries connected to it.
Of course! I should have seen that. This is so for lfn_dir_read() too.
I
On Thu, 18 Mar 2004 11:14:39 +0200, I wrote:
the redirected output contains two consequtive carriage returns though.
I mean that the output file contains extra CRs only after the r and
q input commands, not where DEBUG does its own output.
Good news - I now saw that this is exactly the same
I mean: is this mean, that editing code is/should duplicated in kernel
and command.com?
As far as I know, no. FreeCOM has its own command line editor with history
and auto-competion.
---
This SF.Net email is sponsored by: IBM Linux Tutorials
I mean: is this mean, that editing code is/should duplicated in kernel
and command.com?
As far as I know, no. FreeCOM has its own command line editor with
history and auto-completion.
But:
1. In kernel present editing code.
2. If code presented in command.com, how this affects other programs
The F3-style command line editing is in the kernel because function 0Ah
(3Fh when reading from standard input) in MS-DOS does it. Period. As to
FreeCOM, it has a better (4DOS-style) command line editing and I don't see
a reason for a separate DOSEDIT. Period. I'll not answer anymore.
On Sun, 21 Mar 2004 23:42:26 + (GMT), Bart Oldeman wrote:
It appears that ^C has to be echoed to stdout. This is easy to test, I'm
using a simple test0a program, see below.
If you (in MSDOS) run test0a foo and press ^C then the ^C ends up in
foo.
Or if I run DEBUG BOZA then type ^C and Q
the redirected output contains two consequtive carriage returns though.
I mean that the output file contains extra CRs only after the r and q
input commands, not where DEBUG does its own output.
---
This SF.Net email is sponsored by: IBM Linux
On Wed, 17 Mar 2004 13:37:07 + (GMT), Bart Oldeman wrote:
It looks like a bug in both DEBUG and the kernel.
What happens is the reference count in the SFT gets too high.
1. open: 1
2. int21/ax=4b: 2
3. int21/ax=55: 3 (this function called by debug)
then:
4. int20: 2
5. int21/ah= 3e: 1
... and
On Mon, 15 Mar 2004 22:27:45 +0300 (MSK), Arkady V.Belousov wrote:
a
int 3
g=100
q
Run DEBUGT.DRESULT (where DEBUG is by Paul Vojta, MS-DEBUG doesn't
work under FreeDOS).
This is wrong. MS-DOS 7.10 DEBUG *does* work under FreeDOS 7.10! I've used
it many many times.
Under MS-DOS result file
1 - 100 of 135 matches
Mail list logo
