Hi!
22--2004 12:13 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
LG Thanks! Silly me, I had forgotten to rename the FAT and CPU variables to
LG XFAT and XCPU, so what I was getting was a 8086 kernel! Now, with
Hm. How you miss kbc8632 instead kbc38632?
LG OpenWatcom
Hi!
22--2004 20:29 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
BO download UNSTABLE cvs
BO cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/freedos co
BO -rUNSTABLE kernel
Hm. Is there consequent tarball of cvs tree? Arkady tree is not
very Arkady, so I should sincronize with
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
On Sun, 22 Aug 2004, Luchezar Georgiev wrote:
They had moved the 1.3 from the devel/beta subdirectory onto a new one:
http://downloads.openwatcom.org/ftp/zips-1.3/
I think it's a good sign that they're ready to announce it soon. But Bart
probably knows more ;-)
Michal Necasek just said he
Lucho wrote:
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
tom ehlert escreveu:
Do you really think after having sold thousand copies, I'm a good programmer,
who deserves any dollar he makes, and after selling millions copies
(and having charged money for it) I'll be suddenly an immoral man ?
IMO it will (or propably 'would') still be the same thing:
the
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
Hi!
21--2004 17:43 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
LG I agree, but by buying a second-hand BC copy Bart wouldn't pay the Borland
LG programmers in any way.
Companies like RIAA and MPAA strive against reselling services (like
one on Amazon).
Lucho, impressive progress.
Though I don't use any COUNTRY/codepage/keyboard_layout things myself,
this can be quite usefull.
I can imagine Aitor being happy, for example.
He does a lot with these things.
Now only NLSFUNC is missing (in progress by Eduardo Casino)?
btw, no source for your
Hello Eduardo,
Lucho, Steffen, everybody, we should have some discussion to determine
which COUNTRY.SYS format we should use in FreeDOS.
1'st let me state that I never used NLSFUNC, so I may be the wrong
person.
2'nd, all I needed for FreeDOS was 24 hour time/european date,
and I implemented
Hello Luchezar,
Not only Bulgarians. 3/4 of the world thinks so. And many Americans and
Germans too, by the way.
there is a german saying 'hey guys - eat shit! Billions of flies can't
be wrong'
So we're just billions of flies to you. Very well :) Otherwise it's a
great anti-fashion
Hi,
tom ehlert escribió:
Hello Eduardo,
Lucho, Steffen, everybody, we should have some discussion to determine
which COUNTRY.SYS format we should use in FreeDOS.
1'st let me state that I never used NLSFUNC, so I may be the wrong
person.
Well, neither do I because as I never change
Hello Aitor,
Yes, but as I mentioned, the problem is that, how do we get collating
tables, etc for other countries than US and Germany? We could rely on
user's efforts to create those tables, but this can be quite laborious
(provided that, for copyright issues, the COUNTRY.SYS of the
On Sun, 22 Aug 2004, Aitor Santamaría Merino wrote:
Yes, but as I mentioned, the problem is that, how do we get collating
tables, etc for other countries than US and Germany? We could rely on
user's efforts to create those tables, but this can be quite laborious
Probably best to have a look
Hi Bart,
Thanks for pointing out!
Actually I ignore if Linux works with some notion similar to codepges at
all (I once tried to port a single ASCII chart drawing program from DOS
to Linux and found out lots of blanks #219 in the table.
If Unicode is the only collating table present, as you say
Hi!
20--2004 20:45 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
BO In this case, instead of pursuing a technical solution (Open Watcom is
BO open source so can be changed) to reach a certain goal, you suggest I go
BO for an illegal black-box solution, the cowards' way out. By
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 Luchezar,
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.
there is a german saying
'hey guys - eat
On Thu, 19 Aug 2004, Luchezar Georgiev wrote:
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
On Sun, 15 Aug 2004, Luchezar Georgiev wrote:
Besides, you know that Borland C++ 4.0 produces the smallest possible
packed kernel binary file. Sometimes kernel file size is what matters (for
floppy and ROM disks) and sometimes - the resident size in RAM (where
Watcom is the king), if the DOS
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
Luchezar Georgiev escreveu:
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!
I am very glad that it was usefull.
Alain
Hello Luchezar,
Hallo Eric,
does FreeDOS already support int 2f.122f, set DOS version number?
Now it does - see patch below ;-)
according to RBIL:
INT 2F U - DOS 4.x internal - SET DOS VERSION NUMBER TO RETURN
AX = 122Fh
DX = DOS version number (h = return true DOS
On Fri, 13 Aug 2004, Luchezar Georgiev wrote:
Sure. But since it's easier to make the kernel return a serial mumber of 0
as MS-DOS does than to patch each and every copy of 32RTM.EXE, I changed
our function 30h to return 0 in CX. I tested this change and now 32RTM
works without -X as Michael
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
On Sun, 15 Aug 2004, Luchezar Georgiev wrote:
Hallo Bart,
There's also a pointless optimization, that the compiler can do for us
as well.
Will Watcom (the only compiler you recognise) do this?
Of course, I'm not going to state this without checking.
Borland won't, I'm sure. So my
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
At 11:35 PM 8/11/2004 +1200, Bart Oldeman wrote:
And with that, I'm at the end of the list for finding FreeDOS
incompatibilities unrelated to kernel, shell, and stand-alone FD utilities
again.
There's one FD incompatibility that's been there for some time:
OpenWatcom wd /tr=rsi and wd /tr=cw
Hi,
Bart Oldeman escribió:
ok, that's bit clearer than his email (which was about 10x longer than
necessary, but obviously I'm the only one here who thinks that?).
No, I also agree. I am back today after some days off. Sorry, Eric, I
couldn't read your whole mail, or I would never be able to
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
Hi!
7--2004 17:22 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
LG Arkady, please respond if you read this. How are you?
Fine, thank you.
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
Hi!
8--2004 11:39 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
BO FreeDOS could, say, show the full message if you press a certain F key(as
BO it waits for F5/F8 anyway), like this
BO FreeDOS kernel build 2035a-WHATEVER. Copyright...
BO This kernel comes with ABSOLUTELY NO
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
Hi Arkady,
good to have you back :)
Please send me your email address for direct contact. I sent you a
message that was probably lost :(
Alain
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for
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
Hi,
Eric reported a FindFirst/FindNext bug here in his message:
[Freedos-kernel] 2035 findfirst bug: attr a8 treated as 08 if local
(I included a part of it below in this message).
When I filed bug 1753 (NetWare VLM invalid opcode upon login,
On Thu, 12 Aug 2004, Erwin Veermans wrote:
issue he raised here but good enough for testing. Unfortunately
it broke mkdir so this would need a bit more work than the
3 patch-lines I got from Eric.
Hmm. Stange that it broke mkdir.
[Eric's incomplete patch-proposal]
dosfns.c DosFindNext:
On Thu, 12 Aug 2004, Luchezar Georgiev wrote:
[added by me]: Michael wrote:
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 =
issue he raised here but good enough for testing. Unfortunately it
broke mkdir so this would need a bit more work than the 3
patch-lines I got from Eric.
Hmm. Stange that it broke mkdir.
My fault. It happened that I applied it on a kernel-tar from just
before the 2035-release which
Hi!
7--2004 13:28 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
LG exeflat.c of build 2035a (not 2035) has a problem. The start segment is an
LG argument so it's a variable and its value - 2 must be loaded into DI
LG instead of the constant 0x5E. Here's a fix:
LG +*(short
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
On Wed, 11 Aug 2004, Luchezar Georgiev wrote:
HiNTOS is a DOS extender and Windows emulator that converts Windows
console programs into programs that run in both Windows and DOS. It's the
only one that can convert *fixed* PE executables (WDOSX can't!).
Just in case you didn't know, there's
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!
At 02:22 PM 8/11/2004 +0300, Luchezar Georgiev wrote:
HiNTOS is a DOS extender and Windows emulator that converts Windows
console programs into programs that run in both Windows and DOS. It's the
only one that can convert *fixed* PE executables (WDOSX can't!). It's
available at
At 11:35 PM 8/11/2004 +1200, Bart Oldeman wrote:
There's one FD incompatibility that's been there for some time:
OpenWatcom wd /tr=rsi and wd /tr=cw appear to run just fine when you
debug a program but a crash occurs (black screen, reset only way out, or
invalid opcode) when you exit the debugger.
At 01:02 PM 8/8/2004 +0300, Luchezar Georgiev wrote:
Borland 32RTM 1.5 fails to work in FreeDOS but works in MS-DOS. I've
patched it to make it work by modifying the byte at offset 284h from 0 to
1. The X32 DOS extender used in Digital Mars SMAKE had caused problems, so
I've patched its offset
At 06:39 AM 8/9/2004 +0200, Eric Auer wrote:
I was able to learn more about Win32 loading in Win 3.1 / German this
weekend. For me, the PCI/AGP bus magic for flipping and initializing cards
*crashes* with MS HIMEM (3.07, comes with Win3.1) *unless* you also load
MS EMM386 (4.44, same source),
Hi Tom,
one reason for different behaviour *might* be that smartdrv traps
int25/int26, which is used differently in FreeDOS (not everything is
rooted through it)
I don't think other DOSes route things through int25/int26 either, I
tested that a few years ago. It would be a major headache
On Tue, 10 Aug 2004, Bart Oldeman wrote:
I don't think other DOSes route things through int25/int26 either, I
tested that a few years ago. It would be a major headache anyway as
int25/26 would reset the DOS stack pointer! RBIL explicitly mentions
There is yet another thing why DOS cannot use the
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
Hi!
10--2004 10:02 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
BTW, what if FreeDOS will search (fd)config.sys not on C:, but on real
bootable partition? Kernel knows which disk was used to boot (currently
not preserved - at start of main.c:FreeDOSmain() LoL-BootDrive
At 10:56 AM 8/10/2004 +0300, Luchezar Georgiev wrote:
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
On Tue, 10 Aug 2004, Michael Devore wrote:
Some way or another, it looks 32RTM is unhappy with what is going on with
the stack on the call to function 34h. I don't think the InDOS pointer
itself is what causes the failure because the exception can occur during or
immediately after return
At 11:12 AM 8/11/2004 +1200, Bart Oldeman wrote:
On Tue, 10 Aug 2004, Michael Devore wrote:
Some way or another, it looks 32RTM is unhappy with what is going on with
the stack on the call to function 34h. I don't think the InDOS pointer
itself is what causes the failure because the exception
At 06:44 PM 8/10/2004 -0500, I wrote:
At 11:12 AM 8/11/2004 +1200, Bart Oldeman wrote:
On Tue, 10 Aug 2004, Michael Devore wrote:
Some way or another, it looks 32RTM is unhappy with what is going on with
the stack on the call to function 34h. I don't think the InDOS pointer
itself is what
At 01:02 PM 8/8/2004 +0300, you wrote:
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
At 05:38 AM 8/11/2004 +0200, Eric Auer wrote:
An unanswered question is are you able to successfully install Windows 3.1
itself over FreeDOS? Attempting to do so here aborts the install while it
Yes I were able to do that. I copied all disk contents into 7 directories
first (because I got an
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%
Hello Luchezar,
I use IOCTL every day and that's how I found that the XMSDSK lock bug that
prevented SCANDISK from checking the XMSDSK drive had come back as Arkady
moved the lock check too low. Without anger, I wrote a patch for this, he
accepted it with some minor changes, and - voila!
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
On Mon, 9 Aug 2004, Luchezar Georgiev wrote:
OK, this is a good attestation, but perhaps if there wasn't the current
absurd that using MS-DOS® in any way is illegal (unless you've bought a
legal second hand copy or bought it long ago - hey, I even have a
Certificate for Authenticity for
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
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
Hello Luchezar,
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.
that you
Remember that Steve Gibson went round trip back to FreeDOS after
evaluating several other DOSes so this means that FreeDOS can't be that
bad :)
a) other DOS's were just too expensive
b) his problems seem to have been entirely related to the 2033 kernel
default stacksize of 128 byte
c) he
On Sat, 7 Aug 2004, Luchezar Georgiev wrote:
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.c2004-07-09
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
On Sat, 7 Aug 2004, Luchezar Georgiev wrote:
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 ;-)
I was just
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 Luchezar,
OK, long live the holy conservatism that saves the FreeDOS world
from the Arkadifying hell ;-G By
100% agreed
tom
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal
Hello Luchezar,
I didn't know that there are TWO kernel builds called 2035a... Perhaps you
should call yours 2035b where b = Bart (a = Arkady ;-)
or call the 'optimized' kernel keUNSTABLExxx or keARxxx,
as the main stream kernel should concentrate on FIXING bugs, rather then
introducing new
Bart Oldeman escribió:
By the way, how is Arkady? Has anybody heard of him recently? I begin to
worry about him!
No idea. A bit silent here indeed.
True. Maybe he is on a vacation?
Aitor
---
This SF.Net email is sponsored by OSTG. Have
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
At 09:19 PM 8/7/2004 +0300, Luchezar Georgiev wrote:
Needless to say that these bugs and incompatibilities are only a small
part of the whole picture. You already know the DOS extender compatibility
problems I've reported earlier. Perhaps it's also worth mentioning that
writing files under
Hi Lucho,
Luchezar Georgiev escribi:
100% agreed. Since I use unstable kernel every day in practice, I
think it has no more bugs than the stable one. But during the last
few weeks I noticed several more bugs and incompatibilities present in
both stable and unstable branches, most of them
So, as a prospective user of the kernel, after contributing to it for
more than an year, I can conclude than it's good enough for simpler
tasks not involving writing a lot of long named files on a FAT32
partition. For more complex tasks, however, MS-DOS 7.1, PC-DOS 7.1 and
ROM-DOS 7.1 are more
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 really care
about this!
The Buenos Aires Convention (1911) that required this was superseded by
the Universal Copyright and Berne conventions. More on this at
On Sat, 7 Aug 2004, Luchezar Georgiev wrote:
[problems with DOSLFN and SMARTDRV and some obscure problems for
nonstandard configurations]
So, as a prospective user of the kernel, after contributing to it for more
than an year, I can conclude than it's good enough for simpler tasks not
Bart Oldeman wrote:
Cron was disabled on SF, see
http://sourceforge.net/docman/display_doc.php?docid=2352group_id=1
so the daily tarballs are no longer that (in fact the last one is from
July 12). Somebody would have to manually update or run a cron job
from an outside machine. Or just wait
Hello again,
2. nlsfunc would have to copy anything in between ss:sp and ss:920
(_disk_api_tos, that's the top of the stack used here in any DOS =
4.0) to a temp area (max 384 bytes), set sp to 920, and with that call
DOS. Then after the call adjust the stack pointer, then swap
Hi!
25--2004 16:46 [EMAIL PROTECTED] (Interim FreeDOS Kernel Maintainer)
wrote to [EMAIL PROTECTED]:
IFM http://www.fdos.org/bootdisks/autogen/source_core.UNSTABLE.zip
BTW, PKZIP can't extract file, if its name contains more than one dot.
:( Now I again should binary edit this archive to
Hi!
25--2004 16:46 [EMAIL PROTECTED] (Interim FreeDOS Kernel Maintainer)
wrote to [EMAIL PROTECTED]:
IFM [Kernel + FreeCom + Sys]
IFM .UNSTABLE. is the development branch where work is initially
IFM committed, the other is the stable [HEAD] branch. source:
IFM
On Mon, 26 Jul 2004, Eduardo Casino wrote:
There are. If I understand it correctly, when calling DOS with ss:920,
the flags and return address are trashed because DOS sets ss:920 on
entry, again.
No. The whole point of calling int2f/ax=12xx is that this stack setup is
bypassed.
i.e.
Jeremy:
The [EMAIL PROTECTED] alias is still pointed at Bart. Did you want me
to change it to point to you?
-jh
--
_
This email message has been automatically encrypted using ROT-26.
On Tue, 27 Jul 2004, Bart Oldeman wrote:
On Mon, 26 Jul 2004, Steffen Kaiser wrote:
DOS has three internal stacks, how about switching to the Critical Error
stack and defer any calls when the stack is in use?
You'd automatically overflow into the Critical Error stack anyway. I
So you can set DOS's
Jim Hall wrote:
Jeremy:
The [EMAIL PROTECTED] alias is still pointed at Bart. Did you want me
to change it to point to you?
-jh
Oops. Maybe I should have sent that just to Jeremy Bart. :-)
-jh
--
_
This email
El lun, 26-07-2004 a las 14:09, Bart Oldeman escribió:
No. The whole point of calling int2f/ax=12xx is that this stack setup is
bypassed.
i.e. *without* any swapping in NLSFUNC you'd have
int21/ah=38 = DOS switches to internal stack =
NLSFUNC (still uses DOS stack) = int2f/ax=12xx = back
Hi!
25--2004 09:58 Arkady V.Belousov wrote to
[EMAIL PROTECTED]:
BO Need to check for navc!=NULL, not *nc!=0x in DosGetFree.
BO +++ dosfns.c25 Jul 2004 00:08:34 - 1.71
BO - if (*nc != 0x)
BO + if (navc != NULL)
BO *navc = (COUNT) dos_free(dpbp);
AVB
Hi!
25--2004 06:05 [EMAIL PROTECTED] (Interim FreeDOS Kernel Maintainer)
wrote to [EMAIL PROTECTED]:
IFM UNSTABLE branch updated with many of Lucho's and Arkady's work.
When you update archive on the site? I wish to resync my tree - I was
see in your posts some additions. Also, don't
601 - 700 of 1070 matches
Mail list logo
