Hi Michael, sorry for getting Arkady-ish in my patches.
Here the most useful ones of them:
+ ; All calls can destroy esi, edi, ecx: saved at @@makecall
+ ; None of the calls RETURNS anything in esi, edi, ecx, except
+ ; 58xx and VCPI de0a, which write [esp+2] to return (E)CX.
+ ; If there was OS/E support, 5b and 5b could return ES:DI, CX.
That comment IS useful, because you have a BUG, and future maintainers
will introduce new bugs when they implement OS/E and miss the above point:
nummap:
mov cx,4 ; four mappable pages
+ mov ss:[esp+2],cx ; have to save cx value to stack storage
Bug CONFIRMED by using Manifest, which tells NO mappable pages and NO frame.
- DW OFFSET RESTORE_PAGES
- DW OFFSET NOT_IMPL
- DW OFFSET NOT_IMPL
+ DW OFFSET RESTORE_PAGES ; 48h
+ DW OFFSET NOT_IMPL_FEATURE ; hardware EMS only
+ DW OFFSET NOT_IMPL_FEATURE ; hardware EMS only
This one is useful because you have:
NOT_IMPL PROC NEAR
IF UNIMPLEMENTED_EMS_DEBUG EQ 1
... show some screen output which would remind you to eventually implement ...
ENDIF
MOV AH,84H ; "Invalid function code"
RET
So I added:
+; features which will not be supported
+NOT_IMPL_FEATURE PROC NEAR ; "feature not supported"
+ mov ah,91h
+ ret
+NOT_IMPL_FEATURE ENDP
For RBIL reference:
84h undefined function requested by application
91h feature not supported
By the way, comment improvements do not HURT, do they? So you should
not reject them as part of the patch. EMM386 sources are not very well
commented anyway, and the comments are a strange mix of English and German.
+ DW OFFSET ems4_map_and_jump ; 55h map and jump *** FIXME ***
Yes yes yes. My bad. But look at the fixme:
+; AH = 55h: EMS 4.0 alter page map and jump
...
+ems4_map_and_jump PROC NEAR
... about 60 lines of code ...
+ pop esi ; jump target
+ ; *** SHOULD PUT TARGET ON OUR STACK TO JUMP ON RETURN TO V8086 ***
+ mov ah,80h ; *** FIXME! ***
...
So what? All the code is there, you only have to remove the mov ah,80h
and stick in a mov [esp+???],esi (or two mov, if the V86 CS and IP are
not at adjacent places). The problem is that the stack layout was too
hard to figure out, but I assume that you know it.
Other useful parts of my patch are debug register read/write support
and handle name support, in ALLOCATE_PAGES and DEALLOCATE_PAGES and
of course, most of it, in ems4_get_handle_info, quite long, but will
not inflate EMM386 by kilobytes either.
What else do we have? ems4_alternate_regs and ems4_access_os as proper
stubs which tell that access cannot be granted. Just cleaner than
throwing both into error code "undefined function".
About ems4_get_config: I was tempted to implement "get hardware info",
but was not sure about the to be reported context save area size. For
DR DOS EMM386, it is 2 bytes * 4 pages as far as I know. But they use
4k raw pages. Would be cool if your EMM386 could do 4k raw pages, too,
but that depends on how suitable the VCPI alloc scheme (which already
does use 4k pages) would be for the EMS processing code.
There is a small patch to ems4_handle_names: The handle number should
be treated as byte to avoid overflows (overflows always ask for trouble).
- movzx ecx,dx ; handle (index)
+ movzx ecx,dl ; handle (index)
(at two places there).
I also wrote subfunction 1 support for ems4_map_multi - I know that
many programs just use page numbers instead of segments, but it does
not hurt either that you can now support BOTH, numbers and segments.
Same applies to map-and-jump, which supports both, but is incomplete.
Yes. Shame on me.
Finally, ems4_attribute: Previous implementation always returned AX=0.
Now you get correct error codes if somebody tries to access volatibility
attributes for nonexisting handles or tries to make things nonvolatile.
SURE, programs SHOULD first ask if the feature is supported. Still it is
better to return the right error codes when programs do the wrong thing.
(By the way, error code 90h is probably "even righter" than 91h when
programs ask for making something nonvolatile. Talking about right errors,
it would conceiveably be useful to return error a1h if MORE than ONE
handle matches a search handle by name query. Whatever... Or you can
refuse a set-name which would create a duplicate name... I assume that
if at all, then check for error a1 should be in SET name, NOT in FIND name!)
> In the first screen, I see you correcting typos on
> commented-out messages. Then a comment word typo fix, and changes to
> working but slightly inconsistently declared forms of labels. Oh, and a
> tab change or two...
See the list of useful things and the reasoning about comments above...
> And what is this: You have a FIXME in your added
> code?! Good grief, if you can't be bothered, why should I?
If you want a fixme, check this:
; *** NOT IMPLEMENTED
; AX=DE0B: VCPI set 8259A interrupt vector mappings
...
VCPI_SetMappings PROC NEAR
cli ; ensure interrupts disabled
jmp NOT_IMPL
...
I took the freedom to at least specify WHAT VCPI_SetMappings SHOULD do.
That function even IS used by programs more than alter-and-jump, and only
either implementing the full de0b function or (truly) reporting that
mappings already HAVE been changed when de0a is queried (which results in
other programs not being allowed to change mappings again) will resolve that.
> However, Manifest may stress
> things harder, so I'll test that too.
THANKS! Manifest showed me some interesting differences in DR DOS, MS DOS
and free EMM386 indeed (I own a copy of MS Windows 3.1, so I own MS EMM386).
While I do not really feel like wanting alternate/DMA register sets, I do
feel that it is useful to have MAPPABLE areas outside the page frame. They
are what makes EMS 4.0 more useful than EMS 3.2, after all. A common choice
is to have 256-640k and the UMBs as mappable area, plus, if EMS 3.2 support
is on, the page frame (which always has page numbers 0-3).
Bernd asked:
> Michael, is there some small list or something of apps using EMS, VCPI,
> DPMI, etc?
I have the idea that apps which use EMS often only need EMS 3.2, which is
already fully supported by free EMM386. Apps which use a DOS extender all
need VCPI to coexist with EMM386 (if no EMM386 present, no VCPI needed).
DPMI is only needed for situations where you cannot grant raw (VCPI style)
access, and as an abstraction layer. In fact, many DOS extenders contain
their own implementation of DPMI - in "plain DOS" they use raw access plus
their DPMI, in "DOS with EMM386" they use VCPI plus their DPMI, and in
"DOS box of 32bit environment", they use the DPMI of e.g. Windows.
Something completely different:
> >If you use FreeDOS to load WinCE, please behave better than
> >Neoware.com which have hidden the FreeDOS copyright messages...
> We need a FreeDOS Compliance Engineer!
We are already doing all this work in our free time for nothing apart
from being proud of having a good free DOS, good karma and some applause
from a small fraction of the users. So it really sucks if somebody else
takes all that work, and adds 5 minutes of "work" for compiling his own
version which no longer contains evidence that the community did all the
dirty work behind a product. Okay, loading WinCE with a 1995/1999 FDXMS
and FreeCOM is kind of peanuts, I guess they could even have used some
SHELL=loadce... line without FreeCOM. Actually I wonder why WinCE does
not simply come with a boot sector of some kind. Or does it actually USE
the DOS kernel for something?
Eric
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
