Guys,
I was pretty sure I had got it working before, so I didn't want to just
leave it as it is. What I just did is restart my computer with plain FreeDOS
and wrote, compiled and executed a programme like this:
mov ax,0b800h
mov ds,ax
mov word ptr [100h],1f21h ; draw exclamation mark
mov ax,[12345678h] ; tempt FreeDOS to respond to an exception
mov word ptr [102h],4e3fh ; draw a question mark
mov ax,4c00h
int 21h ; exit to DOS
What happened was that both marks where drawn and no error occurred. At that
point, only HIMEM was loaded, no EMM386. I thought that meant that FreeDOS's
HIMEM did indeed have that routine.
I rebooted the computer with EMM386 and reran the program. Of course, this
time, an exception was triggered. Only the exclamation mark was drawn and the
program exited abnormally. This was quite sensible to me. I tried one more time
not loading any of the two drivers. The first mark was drawn again, but the
system halted, unable to handle the exception.
Then I decided I'd be more drastic, so I wrote another program like this:
xor ax,ax
mov ds,ax
mov word ptr [0b8100h],1f21h ; draw exclamation mark
mov ax,4c00h
int 21h ; exit to DOS
When loading only HIMEM, this did, in fact, cause a mark to be drawn on the
screen. But then I realised it could also be the fact that I was using 4DOS as
the command interpreter. So I rebooted with HIMEM and FreeCOM and the system
hung when I tried to execute the code.
Conclusion: it was 4DOS that was loading this routine and not HIMEM, but as
I had read at some point about HIMEM.SYS doing it, I had thought that was it in
this case. Anyway, this leads me to think it'd be very handy to have a function
or a small application in DOS to enable this behaviour on programmes requests.
Of course, relying on this would render code incomaptible with EMM386 and
emulators such as DOSBox. Am I right? On the other hand, it would be a lot
faster to access memory.
Lucas
PS: Because of a problem with yahoo, you may have received a truncated copy of
this e-mail. Please disregard it. I think I'll switch to GMail
--- On Tue, 27/10/09, japhethx gmail <japhe...@googlemail.com> wrote:
From: japhethx gmail <japhe...@googlemail.com>
Subject: Re: [Freedos-devel] About my driver, HIMEM/EMM386 and interrupts
To: freedos-devel@lists.sourceforge.net
Received: Tuesday, 27 October, 2009, 4:56 PM
>> However, I understood that HIMEM did something like establishing a
>> routine that was run whenever you tried to use an
offset greater than
>> 0FFFFh together with a "real-mode-made" segment. This routine would
>> "trap" the event and handle the switch to protected mode and back,
>> keeping the segment base, but extending the limit to 4G, then returning
>> to the instruction that generated the exception. Am I right? Does this
>> really happen? If so, programs should not mind about their segments
>> being initially setup in real mode.
>
> No, I'm not aware of any Extended Memory Manager (XMM) that does such a
> thing.
MS Himem does indeed "install" such a routine, but it is installed only during
XMS block moves inside Himem.
See the MS Himem source for details. It's Public Domain, IIRC.
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R)
Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Reading this email at work? Make a change with Yahoo!Xtra Jobs
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
