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.
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 exi
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 n
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 implementat
> 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
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
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 o
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 l
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
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 li
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
Imre Leber schrieb:
> You can find it at http://users.telenet.be/imre/FreeDOS/DEFRAG10.ZIP
> Be warned, it can be slow in most methods. "Unfragment files only" works
> pretty descent however, this is for most disks, the default method.
Stability comes first. We can think about optimizing when t
>-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 http
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) w
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
>^^^
>T
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 goo
Hi!
8-Авг-2006 02:50 [EMAIL PROTECTED] (Michael Devore) wrote to
freedos-devel@lists.sourceforge.net:
>> Fine. Archive with build subsystem I re-send you again in next
>> letter. There also will be (again) present patch, to fix compatibility
>> with TC/BC (and it fixes bug in useful.c).
MD>
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 (
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
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 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
---
21 matches
Mail list logo
