I have made all my changes to support FAT32 in defrag. Just needs to be tested.
But I see that my previous version (1.0) was not picked up.
Is there any specific reason?
I could understand if it is not going to be in FreeDOS 1, altough it is highly
recommended.
Imre
It will be in, I just didn't get to adding it at that time (I wanted
to make sure that things didn't fail horrilbly like they did for the
previous version).
On 8/8/06, Imre Leber [EMAIL PROTECTED] wrote:
I have made all my changes to support FAT32 in defrag. Just needs to be
tested.
But I see
At 03:49 AM 8/8/2006 +0400, Arkady V.Belousov wrote, and I reconstituted:
MD Here's my final offer: I'll split off a new subdirectory on the source
MD tree, call it TCBUILD or somesuch (but avoiding the temptation to call it
MD ARKADY), and you can put all your shiny new C source changes in
I meant it wasn't on ibiblio :-)
Imre
-Original Message-
From: Blair Campbell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 8, 2006 09:18 AM
To: freedos-devel@lists.sourceforge.net
Subject: Re: [Freedos-devel] defrag
It will be in, I just didn't get to adding it at that time (I
At 01:32 PM 8/8/2006 +0400, you wrote:
If you wish, I extract for you from Japhet' work fix for sti/ret 2 bug
(in new15 proc)
I already revectored that to the new IRET handling routine when you
mentioned it earlier on list. CMC is slightly neater code, but not enough
to go back in and goof
At 05:11 AM 8/8/2006 -0500, I wrote:
What about fix for issue with DOOM, which you found under VPC?
MD 2) (hopefully) the protected mode
MD stack fix or whatever's going on with certain DOS-extended stuff under VPC
^^^
Testing
I want to test it - could you please post a URL, where I can download it?
Thanks
Flo
On Tue, 08 Aug 2006 09:15:59 +0200, Imre Leber [EMAIL PROTECTED]
wrote:
I have made all my changes to support FAT32 in defrag. Just needs to be
tested.
But I see that my previous version (1.0) was
-Original Message-
From: Florian Xaver [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 8, 2006 12:36 PM
To: freedos-devel@lists.sourceforge.net
Subject: Re: [Freedos-devel] defrag
I want to test it - could you please post a URL, where I can download it?
You can find it at
Imre Leber schrieb:
You can find it at http://users.telenet.be/imre/FreeDOS/DEFRAG10.ZIP
Doh, I should have had a look at it before posting. The source is
included, so please disregard and completely ignore my last message :)
Best regards,
Andre
Hi!
8-Авг-2006 05:11 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
If you wish, I extract for you from Japhet' work fix for sti/ret 2 bug
(in new15 proc)
MD I already revectored that to the new IRET handling routine when you
MD mentioned it earlier on list.
Hi!
8-Авг-2006 05:29 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
What about fix for issue with DOOM, which you found under VPC?
MD 2) (hopefully) the protected mode
MD stack fix or whatever's going on with certain DOS-extended stuff under VPC
At 03:25 PM 8/8/2006 +0400, Arkady V.Belousov wrote:
MD No, doesn't look right. A20 handling was turned off,
Japhet not tun off A20 handling, he just comment out call to INT67/3F.
Which turns off A20 handling enable/disable, unless it's resupported
elsewhere. It's straight-forward
I also read this in RBIL and changed it temporarily to find the /NOX2MAX32
bug and somehow this version has found the way in the Emm386 being uploaded.
But even MS Himem clears BL if it returns AX=1, so there should be no need to
modify anything.
Also the call to INT67/3F was also commented
Imre Leber wrote:
-Original Message-
From: Florian Xaver [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 8, 2006 12:36 PM
To: freedos-devel@lists.sourceforge.net
Subject: Re: [Freedos-devel] defrag
I want to test it - could you please post a URL, where I can download it?
Also the call to INT67/3F was also commented out just temporarily
and reactivated later. It's a feature!!! :)
As this means you temporarily locked the real and virtual A20
to on, and as you call it a feature, I have two comments...
1. toggling the virtual A20 by remapping a few pages is quite
Eric Auer wrote:
Also the call to INT67/3F was also commented out just temporarily
and reactivated later. It's a feature!!! :)
As this means you temporarily locked the real and virtual A20
to on, and as you call it a feature, I have two comments...
I called the current implementation in
Hello Eric,
In summary, I would say it might be nice to have a command
line option lock a20 to on for emm386, for example after
FreeDOS 1.0 is done. You should do some benchmarks on a slow
386sx PC in the meantime ;-). By the way, it also might be
nice to have an option turn a20 on now and
Hi!
8-Авг-2006 06:45 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
So, BL should be modified only in case of error. Not a big deal, I suggest
MD No, I think it is proper to ensure that BL should be set to a nonerror code
MD condition. I won't change the
At 03:50 PM 8/8/2006 +0200, Japheth wrote:
And I disabled this feature temporarily not because of speed reasons, but
because there are situations thinkable where this feature may cause a crash.
Such situations may be rare and almost impossible if DOS is loaded in the
HMA,
but they exist. So if
19 matches
Mail list logo
