Luchezar Georgiev escribiÃ:
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);
wouldn't that be FP_OFS?
break;
What coul
Hi,
Arkady V.Belousov escribiÃ:
LG> Let's concentrate on bgfixing before the imminent FD1 release.
I not object, but this question may be studied _for future releases_.
Isn't? :)
Of course. If it's not to be forgotten, I could annotate it on the
post-1.0 table (currently a badly mixed list
Hello Eric,
>> - lr.CH = REVISION_MAJOR; /* JPP */
>> - lr.CL = REVISION_MINOR;
>> + lr.CX = 0; /* serial number must be 0 or buggy 32RTM thrashes
>> stack! */
> I would vote for lr.CH = 0 lr.CL = *letter*
MSDOS votes cx=0. end of story.
tom
---
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 clea
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 o
Hello Luchezar,
>> 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 number. And it shouldn't have to do that.
An
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 Projec
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
Hi!
11-Авг-2004 14:22 [EMAIL PROTECTED] (Luchezar Georgiev) wrote to
[EMAIL PROTECTED]:
LG> RAR 3.30 (its DOS version fails
LG> to modify existing archives but its Windows console version can do it).
Do you report this to Eugeny? I may do this myself, if you explain me,
how to reproduce thi
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 Medi
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 numbe
At 09:18 AM 8/13/2004 +0300, Luchezar Georgiev wrote:
I tried "int 0x21 ah=0x34" in both MS-DOS 7.10 and FreeDOS. In both, the
returned offset in BX is 321h although the segment in ES is slightly lower
in MS-DOS than in FreeDOS (C9h vs D2h). But in both cases, the memory
location pointed to by E
My working machine died, so I currently change my machine, disks and OS.
Good luck with your new PC, and may you have at least one FAT32 volume! :)
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for
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
Hallo Bart,
case 0x34:
lr.ES = FP_SEG(&InDOS);
lr.BX = FP_SEG(&InDOS);
break;
What could be wrong here?
Copy and paste is broken where you are.
Not copy and paste, my head is broken because I typed it by hand! ;-)
with
lr.BX = FP_OFF(&InDOS);
it would be corr
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> +*
At 11:57 PM 8/12/2004 +1200, Bart Oldeman wrote:
> The InDOS flag value itself?
with
lr.BX = FP_OFF(&InDOS);
it would be correct. But that's what it does in my source so...
> Stack usage during the call?
that's what I suspected. Eric suggested (in a private email) to make
int21/ah=34 reen
> > 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 w
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);
>
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 DosFindN
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,
http://www.freedos.org/bugs/bugzilla/show_bug.cgi?
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 us
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 it
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 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 http://www.alex-h
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!
p
Wed, 11 Aug 2004 23:46:27 +1200 (NZST), Bart Oldeman
<[EMAIL PROTECTED]>:
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*
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
On Tue, 10 Aug 2004, Michael Devore 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 appe
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, Bart Oldeman wrote:
Hello Bart,
The section is not from me, but it simply is to inform a multitasking
scheduler that something bad happens currently -- in a simple case it's
just an extended InDOS flag.
ASSIGN has to issue these calls, too, I believe to inform a protected mo
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 o
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 up
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 ca
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
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 01:43 PM 8/8/2004 +0300, Luchezar Georgiev wrote:
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.
Well, I can tell you where it's happen
Well, UNPAQ.EXE says it needs 32RTM.EXE when executed and DPMI32.PAK
just sits there completely inert, so apparently there is a bit more to
the process than having the two files.
A Catch 22 situation - each file needs the other (UNPAQ.EXE needs
32RTM.EXE that is in DPMI32.PAK to execute, but DPM
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
http://www.saigontech.
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->Boo
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
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 pl
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 an
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), stran
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 4
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 MS
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 in
Hello Luchezar,
>> 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 it?
the kernel talks directly to int13 and never uses int25 internally.
>> a) he implemen
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 it?
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! P
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% mix
>> 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)
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.
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 Lu
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
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
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
> invol
> >> 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
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
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 the
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 DOSLF
Luchezar Georgiev wrote:
Hallo Bart,
...
#define BUILD "2035a"
#define SUB_BUILD "-UNSTABLE"
oops, I see it should be BUILD 2035 with SUB_BUILD a-UNSTABLE
I don't know why some people started calling 2035a-UNSTABLE plain
2035a... perhaps just too lazy to type "-UNSTABLE". But it re
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
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 you
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
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 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 yo
Hello Lucho,
> the build & version dualism (e. g. version should be 2.0.35), but I know
> that neither this,
Actually a couple of years ago it was build 1937 for version 1.0.2 ;)
> nor removal of phrases like "All Rights Reserved." that
> are useless now,
Pat sent an email to this list -- here'
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"
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 w
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:
> 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 04:16:
Bart Oldeman wrote:
Cron was disabled on SF, see
http://sourceforge.net/docman/display_doc.php?docid=2352&group_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 unti
Hi Arkady,
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 replace
kernel.UNSTABLE.source.zip by something like kernel-UNSTABLE-source.zip...
This one ca
On Sun, 25 Jul 2004, Kenneth J. Davis wrote:
> This is largely a cvs issue regarding line endings. Several batch
> files were committed with \r\n line endings from a non-EOL converting
> cvs client, as such on those clients they check out as \r\n, but on
> clients (such as I use) they are convert
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
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 messag
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
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.
-
> > This has nothing to do with switching kernel stacks, in fact if FreeDOS
> > would do things this way (instead of calling DosSeek directly) it would
> > use even more stack space.
>
> Excuse me if I'm a bit thick in the head. Do you mean that it makes no
> sense to implement the int 2f122[6-9b]
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
wonder about "defer" though -- how do you defer a critic
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. *witho
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> http://www.fdos.org/bootdisks
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 t
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 sw
On Sat, 24 Jul 2004, Bart Oldeman wrote:
Hello Bart,
DOS has three internal stacks, how about switching to the Critical Error
stack and defer any calls when the stack is in use?
Bye,
--
Steffen Kaiser
---
This SF.Net email is sponsored by BEA We
Hi!
25-Июл-2004 16:46 [EMAIL PROTECTED] (Interim FreeDOS Kernel Maintainer)
wrote to [EMAIL PROTECTED]:
>> see in your posts some additions. Also, don't forget to publish URL for
IFM> These are fairly static URLs, and should be updated within a day of
IFM> any cvs commits.
At which time? Fo
Arkady V.Belousov wrote:
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
sourceforge has cron jobs
Hi Bart,
> This has nothing to do with switching kernel stacks, in fact if FreeDOS
> would do things this way (instead of calling DosSeek directly) it would
> use even more stack space.
Excuse me if I'm a bit thick in the head. Do you mean that it makes no
sense to implement the int 2f122[6-9b]
Arkady V.Belousov wrote:
Hi!
25-Июл-2004 09:55 [EMAIL PROTECTED] (Kenneth Davis) wrote to
[EMAIL PROTECTED]:
KD> +++ autoexec.bat25 Jul 2004 09:55:56 - 1.6.2.1
KD> @@ -1,3 +1,3 @@
...
Hm. What here changed? Why diff shows all lines as changed?
This is largely a cvs issue regarding
Салям!
25-Июл-2004 17:18 Arkady V.Belousov wrote to
[EMAIL PROTECTED]:
KD>> +++ history.txt 25 Jul 2004 09:55:56 - 1.78.2.3
KD>> + Changes Tom
KD>> * inthndlr.c
KD>> - improve handling of case where eg. FindFirst(I:\*.*) fails, causes
KD>> Int24,
AVB> This patch inclu
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 fo
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>
On Sat, 24 Jul 2004, Eduardo Casino wrote:
> El sáb, 24-07-2004 a las 13:50, Bart Oldeman escribió:
>
> > It's a difficult question. Essentially there are two ways we can go:
> > 1. if the kernel very carefully minimizes stack usage on the code path
> >taken and NLSFUNC itself only uses a co
Hi!
25-Июл-2004 00:33 [EMAIL PROTECTED] (Eric Auer) wrote to
[EMAIL PROTECTED]:
EA> Hi Arkady! Your patch is MUCH too long.
EA> I doubt that you did try to keep the diff short AT ALL.
Eric, may be you test this patch instead criticizm? May be, it already
fixes your problem with WHICHFAT?
Hi!
24-Июл-2004 22:17 Arkady V.Belousov wrote to
[EMAIL PROTECTED]:
AVB> - bugfix: INT21/29: into FcbParseFname() was not passed options from AL.
Forget to mention: casually :) this bugfix reduces resident code (in
inthndlr.c) by ~50 bytes. :)
---
Hi!
22-Июл-2004 21:24 [EMAIL PROTECTED] (tom ehlert) wrote to Eric Auer
<[EMAIL PROTECTED]>:
>>> please provide exact code sequence where it DOES return nonsense - and
>>> I'll fix it. (we are talking about ke2035 !!)
>> That translates to: Provide a fix and you will have provided a fix. Helpful.
El sáb, 24-07-2004 a las 13:50, Bart Oldeman escribió:
> It's a difficult question. Essentially there are two ways we can go:
> 1. if the kernel very carefully minimizes stack usage on the code path
>taken and NLSFUNC itself only uses a couple bytes of stack in between
>it's possible to
Hi!
21-Июл-2004 23:33 [EMAIL PROTECTED] (Eric Auer) wrote to
[EMAIL PROTECTED]:
>> there is no 32/16 and 32%16 compiler support, only 16/16 and 32/32.
>> end of story.
EA> Compiler weakness :-P.
Caused by language(s) nature (which require to automatically promote
integral types in expressio
On Sat, 24 Jul 2004, Eduardo Casino wrote:
> Tom, your patch seems to cause some problems (now the wrong DS is passed
> to some nlsfunc calls. It happens with a modified nls.c, I can send you
> the code and the details if you are interested)
If you don't initialize r.ds in a call to intr there is
901 - 1000 of 1804 matches
Mail list logo
