Hi!
26-Июл-2006 14:41 [EMAIL PROTECTED] (Michael Devore) wrote to
:
>> > Well, heck, if I already to have to change some A20 behavior to get a few
>> > ancient programs to work with that idiotic EXEPACK 0h address-wrapping
>> > (assuming EXEPACK makes A20 calls),
>>*VERY* early PKLITE (~1992)
At 03:23 AM 7/27/2006 +0200, Eric Auer wrote:
>Eric indicated I need to allow local A20 control, but
>as it turns out, that won't help. EXEPACK code simply doesn't call
>A20
>routines, so EMM386 cannot fix this problem. It never "sees" the
>wrap
>occurring. The situation has to be corrected
Hi!
25-Июл-2006 11:58 [EMAIL PROTECTED] (Eric Auer) wrote to FreeDOS Devel
:
EA> You said that the "if no MBR 55aa found, replace ALL code and
EA> partition data in the MBR with an empty MBR" function in FDISK,
EA> which has caused a lot of data loss in the past, would be
EA> necessary to handle
Of course it shour have a NULL code...
Aitor Santamaría escreveu:
> Yup? What Scancode would the ANY key have? ;-
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get
At 02:24 PM 7/26/2006 +0200, tom ehlert wrote:
>INT xx enters the interrupt handler with IF cleared, so this should be
>done also when being rerouted through the v86_monitor; looks like a
>plain bug to me
> > Changing a long-standing fundamental behavior to fix a single problem in a
> > virtual
At 09:02 PM 7/26/2006 +0200, tom ehlert wrote:
> > Well, heck, if I already to have to change some A20 behavior to get a few
> > ancient programs to work with that idiotic EXEPACK 0h address-wrapping
> > (assuming EXEPACK makes A20 calls),
>*VERY* early PKLITE (~1992) versions had the same bug
Yup? What Scancode would the ANY key have? ;-
2006/7/26, Alain M. <[EMAIL PROTECTED]>:
>
>
> tom ehlert escreveu:
> > Oops. the keyboard driver is buggy and doesn't recognize the
> > Any key as any key.
>
> Please send this to Aitor, for fixing
>
> Alain
>
>
> -
At 06:20 PM 7/18/2006 +0200, Japheth wrote:
>There is a bug left in the FD-Himem.exe memory manager.
>
>When a program that had allocated several XMS blocks doesn't release these
>blocks in the order FD-Himem likes it, it will report a too small "largest
>free block". Luckily the memory is not "p
tom ehlert escreveu:
> Oops. the keyboard driver is buggy and doesn't recognize the
> Any key as any key.
Please send this to Aitor, for fixing
Alain
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.
Hi Michael, Japeth,
>> > QEMU has never liked CTMOUSE under FreeDOS, and possibly MS-DOS. I don't
>> > know why.
>>
>>when I modify emm386.asm, proc v86_monitor, so that the IF in real-mode is
>>cleared for all interrupts routed to v86-mode, not just the IRQs, it works
>>with CTMOUSE in qemu.
>>
> environment. Even better would be a good explanation for why the problem
> only manifests itself with that specific environment and application.
I've looked into the Qemu BIOS code for int 15h, ah=C2. Usually the code found
in "real" BIOSes is programmed very "defensively", that is, if a piec
At 07:01 AM 7/26/2006 +, Imre wrote:
>Isn't it more logical to change ctmouse then?
Depends on what is actually at fault, i.e. violating spec'ed behavior. I
don't have a good answer for that, yet.
-
Take Surveys. Earn
Isn't it more logical to change ctmouse then?
Imre
>-Original Message-
>From: Michael Devore [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, July 26, 2006 05:35 AM
>To: freedos-devel@lists.sourceforge.net
>Subject: [Freedos-devel] 2nd FreeDOS 1.0 Testing release
>
>At 09:48 PM 7/25/2006 +020
13 matches
Mail list logo
