GEOS/NDO info for RBIL62?
Matthias Paul
I am preparing some stuff for the forthcoming Ralf Brown´s
Interrupt List 62
http://www.pobox.com/~ralf/files.html
and just checked that there is not a single mentioning
of PC/GEOS or New Deal Office in the list so far...
OK, GEOS is an OS environment in its own, but there are
certainly some special interactions with the host operating
system DOS, which should be documented in RBIL. This info
might be very important for programmers of DOS device
drivers (say, some keyboard drivers or screen savers)
or even alternative DOS kernels such as FreeDOS.
- I am not a GEOS programmer myself (yet ;), but if its
programming model is interrupt or far-call drivern,
there certainly is a place for it in RBIL, either in
INTERRUP.LST or in FARCALL.LST.
- Is there something like a startup/shutdown broadcast
(like the Task Switcher/Windows broadcasts INT 2Fh/
AX=4B05h/AX=4B06h/AX=1605h/AX=1606h) GEOS/NDO issues
when it starts up, so that DOS drivers are acknowledged
that GEOS is about to run and possibly can intercept
this process or provide some special info back to it,
in case it would not be safe to run for some reasons
(I can think of many reasons).
Similar, is there a broadcast issued, when GEOS/NDO
fires up DOS tasks (with or without the DR-DOS TASKMAX/
TASKMGR)?
If there are are no such broadcasts, I think it would be
very important to add something like this in a future
version (in case there will ever be one), even if they
have not been needed so far.
- Is there an installation check interrupt, which could be
called by DOS drivers to see if and which version of
GEOS/NDO is currently running?
- Apparently GEOS/NDO or at least its drivers have intimate
knowledge of the underlaying DOS disk subsystem, hence all
these different DRI.GEO, MS3.GEO, MS4.GEO drivers. Does
someone know, which specific values, structures, or
interrupts GEOS/NDO relies upon, so that the FreeDOS
developers could take care of that these criteria are
met, so that GEOS/NDO runs there as well. Similar for
other drivers.
- Are there any known bugs (even already fixed ones),
limitations, workarounds, or usage quirks, which may
affect the host system, say, the usage of the BIOS
data area in segment 40h or a work around for a bug
in a DOS device driver, which GEOS/NDO relies upon?
For example:
I found GEOS/NDO to be very limited in its use of COM ports,
as - astonishing enough for a program developed in the 1990th -
it does not appear to use the port addresses for the serial
ports provided by the system BIOS and DOS in segment 40h.
So far I was not able to use my modem, which is on COM4 configured
to an I/O address of 260h with IRQ 9 instead of the standard I/O
address 2E8h/IRQ 3 (which would be conflicting with modern video
cards).
Four COM ports and the address of 260h are correctly set up in
the BIOS segment 40h, and other DOS and Windows modem software
can use this without any problems, but GEOS/NDO refuses to use
this info.
I was able to find the hard-wired addresses in some of the
GEOS drivers like SERIAL.GEO, HPREFCN.GEO, and PREFCOMP.GEO
and patched them to 260h, and it accepts the port settig now.
However my UART uses IRQ 9 (which is /not/ used by the video
card on my system, and I cannot change this, as all other IRQs
are in use already), but NDO 3.2A always falls back to 7 when
I select 9 in preferences, so the port is still not useable,
and I have not yet found a way to patch this as well. Anyone?
IMHO, these are serious shortcomings in the way how NDO
interacts with the underlaying host environment, and I think
they should be addressed in possible future issues.
But I also think they should be documented in RBIL,
so that people know about them, and can try to work around
them if possible.
Hence, do you know of similar quirks in other places?
If the info you can provide would be too large to be posted here,
please feel free to contact Ralf (or me) directly, so that it can
be included in the forthcoming issue.
Thanks and Greetings,
Matthias
--
<mailto:Matthi...@post.rwth-aachen.de>; <mailto:mp...@drdos.org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
Edward Di Geronimo Jr.
> OK, GEOS is an OS environment in its own, but there are
> certainly some special interactions with the host operating
> system DOS, which should be documented in RBIL. This info
GEOS pretty much only interacts with DOS for disk access. It'll also use
an memory manager in use (i.e. HIMEM), but that's not required as it can
do the job itself.
> might be very important for programmers of DOS device
> drivers (say, some keyboard drivers or screen savers)
> or even alternative DOS kernels such as FreeDOS.
GEOS handles the keyboard itself, and mixing DOS screen savers isn't a
good idea.
> - I am not a GEOS programmer myself (yet ;), but if its
> programming model is interrupt or far-call drivern,
> there certainly is a place for it in RBIL, either in
> INTERRUP.LST or in FARCALL.LST.
It's complicated... you're not going to understand it unless you have a
good idea of how GEOS works. About all that would be useful is GEOS uses
interrupts 80h - 8Fh internally for function calls. You can't really
interface with it, you have to let the kernel do it all.
> - Is there something like a startup/shutdown broadcast
> (like the Task Switcher/Windows broadcasts INT 2Fh/
> AX=4B05h/AX=4B06h/AX=1605h/AX=1606h) GEOS/NDO issues
> when it starts up, so that DOS drivers are acknowledged
> that GEOS is about to run and possibly can intercept
> this process or provide some special info back to it,
No, nor do I see why it would be needed.
> in case it would not be safe to run for some reasons
> (I can think of many reasons).
> Similar, is there a broadcast issued, when GEOS/NDO
> fires up DOS tasks (with or without the DR-DOS TASKMAX/
> TASKMGR)?
No... GEOS pretty much shuts down completely when you start a DOS task.
Dunno much about the TaskMax stuff tho.
> - Is there an installation check interrupt, which could be
> called by DOS drivers to see if and which version of
> GEOS/NDO is currently running?
No...
> - Apparently GEOS/NDO or at least its drivers have intimate
> knowledge of the underlaying DOS disk subsystem, hence all
> these different DRI.GEO, MS3.GEO, MS4.GEO drivers. Does
> someone know, which specific values, structures, or
> interrupts GEOS/NDO relies upon, so that the FreeDOS
> developers could take care of that these criteria are
> met, so that GEOS/NDO runs there as well. Similar for
> other drivers.
It's pretty much all int 21h. I don't know more detailed. It doesn't mess
with structures directly, it's all interrupt calls to let DOS do the work.
> - Are there any known bugs (even already fixed ones),
> limitations, workarounds, or usage quirks, which may
> affect the host system, say, the usage of the BIOS
> data area in segment 40h or a work around for a bug
> in a DOS device driver, which GEOS/NDO relies upon?
GEOS definately checks values in the BIOS data segment to get system
config.
> I found GEOS/NDO to be very limited in its use of COM ports,
I'm not familiar with that part of the system.
Ed
Matthias Paul
>> might be very important for programmers of DOS device
>> drivers (say, some keyboard drivers or screen savers)
>> or even alternative DOS kernels such as FreeDOS.
>
> GEOS handles the keyboard itself, and mixing DOS screen savers
> isn't a good idea.
Yes, I have experienced that. :-(
>> - I am not a GEOS programmer myself (yet ;), but if its
>> programming model is interrupt or far-call drivern,
>> there certainly is a place for it in RBIL, either in
>> INTERRUP.LST or in FARCALL.LST.
>
> It's complicated... you're not going to understand it unless you have a
> good idea of how GEOS works. About all that would be useful is GEOS uses
> interrupts 80h - 8Fh internally for function calls. You can't really
> interface with it, you have to let the kernel do it all.
Now, that´s already something very important to know. Thanks.
Why is it, that GEOS needs a total of 16 (!) interrupts?
A single entry point should have been sufficient, IMHO...
What happens if someone not being aware of GEOS would choose
INT 80h as an API entry point into his DOS TSR? If you look
at RBIL61, most of the interrupts in this range were only used
by BASIC or APL, but some also for Token Ring network adapters,
NETBIOS, Phar Lap DOS extenders, etc. This basically means that
GEOS would interfere with these other drivers or applications.
Anyway, RBIL contains many functions which are not actually
callable as interrupts and are only using internally; even
the DOS kernel uses similar techniques in some of its internal
interfaces.
If you can provide more detailed info on this (either here
or in e-mail), this would definitely be interesting for RBIL,
and may also help making people more aware of the fact that
GEOS exists, and some may even start writing drivers or
applications for it...
>> - Is there something like a startup/shutdown broadcast
>> (like the Task Switcher/Windows broadcasts INT 2Fh/
>> AX=4B05h/AX=4B06h/AX=1605h/AX=1606h) GEOS/NDO issues
>> when it starts up, so that DOS drivers are acknowledged
>> that GEOS is about to run and possibly can intercept
>> this process or provide some special info back to it,
>
> No, nor do I see why it would be needed.
It would be very important! Just two examples:
Assume a DOS screen saver would not be compatible with GEOS
(as most screen savers are not). It could then intercept the
broadcast and either prevent GEOS from running, so that GEOS
would display a message like "Cannot run due to driver objection.
Press key to exit and reconfigure system", and return to the
prompt, or the screen saver could temporarily suspend itself
until GEOS is shut down again (you probably know that *many*
DOS drivers do adapt themselves to the environment changes
when Windows starts up in a very similar fashion), or the
screen saver could inform GEOS how to directly talk to it,
so that the external DOS screen saver would be used and controlled
by GEOS instead of it´s own internal one. I can see several
reasons, why on some systems a DOS screen saver might be preferable
over GEOS´ own one. Just think, that it might directly talk to
the security module loaded in DR-DOS, as for example the DR-DOS
screen saver LOCK does, but the GEOS screen saver does not.
Also, a DOS keyboard driver, like our advanced FreeKEYB
driver, might provide rare national keyboard layouts or
codepage settings, user customized or otherwise special
layouts like Dvorak, Maltron, Octima, etc. which are not
supported by GEOS itself. It may also support non-standard
keyboard controller hardware or non-standard exotic keyboards
like 122-key workstation keyboards or these odd "internet"
keyboards. It may provide macro facilities, an extended
keyboard buffer with copy & paste, keystacking, and input/
output redirection functions, built-in calculator and base
converter, and many other features, which are not known by
the default DOS driver KEYB or the driver built into GEOS.
Some of these features /could/ be implemented as GEOS
applications or accessories, but they may be less convenient
to use for some purposes.
So, I think it would be a good idea, if GEOS would provide
means to better interact with the host environment. For
a keyboard driver, simple call out and call back mechanism
could be established (well, some already exist in the DOS
environment, think of INT 15h/AH=4Fh, but there are a few
more), so that GEOS could use the DOS driver instead of its
own driver, or at least let the DOS driver trace the keyboard
events happening inside GEOS. This might also cure various
potential screen saver, cache, or reboot problems.
To continue with my example, our keyboard driver FreeKEYB
also contains an embedded screen saver, and I simply miss
some of FreeKEYB´s features inside of GEOS. Since FreeKEYB
uses our dynamic dead-code-elimination to optimize its
memory image for the target environment at load time, I would
certainly like to add special support into FreeKEYB for GEOS
which could be controlled by a command line option, so the
extra code is only loaded when GEOS is used as well. But
apparently, there´s nothing I could hook into to make the
connection with GEOS unless I would write a GEOS keyboard
driver myself, which just works as a stub for an external
driver. BTW. At which level does GEOS read keystrokes? Hardware
(port 60h) or INT 09h?
As nice as GEOS is in its own context, we should not forget,
that PC/GEOS runs on DOS, and from the viewpoint of DOS,
GEOS looks only like a big "ill-behaving" application which
does not adhere to some of the standards established in the
DOS world, but - if I understood you correctly - also does
not provide means to intercept some of its services or to
interface to it. That´s simply not what any well-written
program should do, IMHO.
Of course, the situation is similar with Windows, which even
goes so far as to patch around in DOS. However, Windows provides
APIs so that the DOS and the Windows parts can "communicate"
with each other. And other applications, like Word or WordPerfect
which also bypass the DOS keyboard driver all have options
to disable these features, and they too provide APIs to talk
to external drivers.
If I understood you correctly, GEOS does not provide similar
means at the present stage, and I´m afraid, this might be part
of the reasons, why GEOS had only limited success on the desktop
so far. Desktop users simply expect that an application is
well-behaving in terms of the underlaying operating system
(this is a bit more vague for DOS than for other operating
systems, but still there are rules, and GEOS does not conform
to all of them, unfortunatly).
Users want to use the software they already own and use for years,
and telling them, this or that is not compatible and must be
removed for GEOS to run, will certainly distract them, in particular
when they want to continue to use their other DOS applications,
which may require these other drivers.
The good thing is, to make GEOS a "well-behaving" DOS application
would be fairly easy by establishing such mechanisms with minimal
overhead for the OS itself, but it would only be possible, if
GEOS development would continue, of course...
>> in case it would not be safe to run for some reasons
>> (I can think of many reasons).
>> Similar, is there a broadcast issued, when GEOS/NDO
>> fires up DOS tasks (with or without the DR-DOS TASKMAX/
>> TASKMGR)?
>
> No... GEOS pretty much shuts down completely when you start
> a DOS task. Dunno much about the TaskMax stuff tho.
Well, I have run some tests with the old DR DOS 6.0 TASKMAX,
the DR-DOS 7.03 TASKMGR, as well as my own enhanced issue of
TASKMGR, which reintroduces the missing copy & paste functionality,
has an extended API, and has enhanced functions to control the
memory usage. GEOS (that is NDO 3.2A) works (in most cases),
but there would be definitely a few things to improve in the way
how GEOS talks to the DR-DOS task manager API. To make this
combination run smooth in all cases, they could be easily addressed
in a possibly future issue of GEOS (it wouldn´t be very complicated
and could be done in a few hours I guess), but at the current stage
I am also trying to detect GEOS from inside TASKMGR so that TASKMGR
can adapt to some of GEOS´ slightly quirky ways to talk to it and
thereby tries to make the best of the situation, while not arti-
ficially restricting its capabilities for other potentially client
GUIs - at the moment I am only aware of ViewMAX, StarTrek, and
GEOS/NDO, but with all these new DOS based GUIs like Qube, Seal,
System 2001, or FreeGEM showing up recently there soon might
be a few more. So far the only pattern I could find is that
NDO explicitly sets a task name of "NewDeal" while TASKMGR
itself would have identified it simply as "LOADER".
I assume, the old GEOS used the string "GEOS" instead, but I
have no original GEOS 1.x/2.0 here for testage. Can someone
confirm the "GEOS" string (the exact writing would be important
for me to know)?
BTW. So far I have done only very limited testing to isolate
the problem, but why is it, that I always get EMM386 protection
faults when I have selected one of the Task Managers in
Preferences, and try to start a DOS task while TASKMGR is
*not* loaded before starting GEOS? Is this a known problem?
Shouldn´t GEOS just fall back to use the NOTASK.GEO driver
then? Apparently it doesn´t, or at least not in exactly the
same way as it does, when none of the Task Managers is selected
at all in Preferences...
Well, since configuring Preferences to No Task Manager fixes
the problem, and loading TASKMGR before GEOS will also work,
this seems to imply a small bug somewhere in TASKMAX.GEO or in
the code which calls it, but I will probably have to run a few
more tests to be absolutely sure about this...
>> - Is there an installation check interrupt, which could be
>> called by DOS drivers to see if and which version of
>> GEOS/NDO is currently running?
>
> No...
As you see from the examples above, it´s badly needed IMHO...
It would not be needed, if GEOS would not have any impact on
the host OS, but since it takes over some services and uses
the physical input and output devices, while leaving other
things for the host to do, it can hardly be seen as a "black box",
which is just loaded by the host. There certainly should be
a way for the host (or its drivers) to find out that GEOS is
up and running, so that the combination can be made working
smoothly together.
I think, this is not an issue for closed embedded systems, where
the user only works inside of the GEOS environment and may not
even be able to exit it and where the implementor has full control
over the loaded DOS drivers. But on a normal desktop, for which NDO
is/was targetted, NDO would have to stick to the established rules
for well behaving DOS applications, or it may create unnecessary
incompatibilities...
>> - Apparently GEOS/NDO or at least its drivers have intimate
>> knowledge of the underlaying DOS disk subsystem, hence all
>> these different DRI.GEO, MS3.GEO, MS4.GEO drivers. Does
>> someone know, which specific values, structures, or
>> interrupts GEOS/NDO relies upon, so that the FreeDOS
>> developers could take care of that these criteria are
>> met, so that GEOS/NDO runs there as well. Similar for
>> other drivers.
>
> It's pretty much all int 21h. I don't know more detailed.
> It doesn't mess with structures directly, it's all interrupt
> calls to let DOS do the work.
That´s good. But why are then several different drivers needed
for GEOS? The documented areas of the disk I/O part of the
INT 21h programming interface have changed only marginally
between DOS 3.31 (which was emulated by DR DOS 3.31+) and
DOS 7.0, and even DOS 7.10 with FAT32 changed only few things
in this area. So, what are the differences between these drivers?
>> - Are there any known bugs (even already fixed ones),
>> limitations, workarounds, or usage quirks, which may
>> affect the host system, say, the usage of the BIOS
>> data area in segment 40h or a work around for a bug
>> in a DOS device driver, which GEOS/NDO relies upon?
>
> GEOS definately checks values in the BIOS data segment to
> get system config.
That´s what I had expected as well, but apparently it does
not do this in all cases, or at least it discards some of
the values, or does not use them in the best-most-possible
way...
>> I found GEOS/NDO to be very limited in its use of COM ports,
>
> I'm not familiar with that part of the system.
What a pitty... I would love to help out in the device driver,
DOS/Linux kernel, or hardware area, as I would like to see the
combination of DR-DOS and GEOS win, well, sorry for the pun... ;-)
In fact, DR-DOS´ 32-bit preemptive multithreading/multitasking
kernel with VMs and its memory manager with DPMS (to run enabled
DOS drivers in Extended Memory and Protected Mode) and DPMI (to
run Extended DOS applications) provides a core architecture quite
similar to that of Windows 9x, but at a lower resource footprint.
But it lacks a decent GUI.
And GEOS would fit in nicely, I think, at least if it could be made
a bit more DOS compatible and maybe could be ported to run in
Protected Mode (for example with DR-DOS DPMS - DOS Protected Mode
Services) to solve the current memory limitations. For 16-bit code
this would even be possible on 286er CPUs.
Well, without at least the GEOS core being open sourced, I don´t
see a realistic chance to let this happen, although it would
probably be a great thing, don´t you think? :-)
Thanks, Edward, for you prompt answers. They are most welcome.
Marcus Groeber
>>It's complicated... you're not going to understand it unless you have a
>>good idea of how GEOS works. About all that would be useful is GEOS uses
>>interrupts 80h - 8Fh internally for function calls. You can't really
>>interface with it, you have to let the kernel do it all.
>>
>Now, that愀 already something very important to know. Thanks.
>
>Why is it, that GEOS needs a total of 16 (!) interrupts?
>A single entry point should have been sufficient, IMHO...
>
I don't even think it is as complicated to explain to someone who knows
a bit of Assembly, which is what I assume readers of the RBIL do. :-)
The reason Geos needs 16 interrupts is because the scheme is used to
convert inter-segment ("far") function calls into interrupts, without
changing the size of the code. The reason this is done so that
"something" (the kernel) can hook itself into every inter-segment call
made by a Geos application and make sure that the proper code segments
are loaded from virtual memory and locked down. In DOS terms, this would
be comparable to an overlay loader, but one that can be added without
requiring explicit support from the compiler or the application.
What happens is something like this:
1. The real mode compiler generates an instruction like this:
CALL <segment>:<offset> -> 9A <offlow><offhigh><seglow><seghigh>
with <seglow><seghigh> normally being defined as an address that must be
fixed up at load time depending on the address where the code has been
placed.
2. The Geos linker turns this into something else:
INT 8xh -> CD 8x
DB <seghigh>,<offlow>,<offhigh>
[Note: without additional research, I can't guarantee for the exact
order of the three data bytes.]
Note that this is again five bytes, so it can be fixed up "in place".
Now the problem is that an interrupt requires two bytes, while a CALL
FAR instruction only needs one. As a result, the 32-bit vector
(<seg><ofs>) must be compressed into 24 bits.
This is achieved by two things: First, the <seg> adress is encoded as a
"handle" to the segment, whose lowest nibble is always zero. This saves
four bits. In addition (and this answers your question) the remaining
four bits go into the low nibble of the interrupt vector, thus creating
anything from INT 80h to 8Fh.
The interrupt handler for all those vectors is the same. It will
"unpack" the adress from the three-and-a-half byte notation, look up the
absolute address of the segment, and forward the call, after having done
its virtual memory loading thing... Return from the call will also pass
through the corresponding unlocking code.
It also implies that Geos performance is critically dependent on good
EMM386 performance (because of interrupt latency), and that FAR jumps
are unusually expensive.
I would expact a similar scheme to exist in Windows 3.x "Real Mode", but
I have never analyzed it in detail.
>What happens if someone not being aware of GEOS would choose
>INT 80h as an API entry point into his DOS TSR? If you look
>
The only effect would be that you couldn't call that API while Geos is
running. Anyway, calling arbitrary software interrupts from within Geos
is not a good idea anyway, because Geos runs all code under the control
of a preemptive scheduler and with most hardware interrupts captured and
modified, so any higher-level TSR might not feel very happy in this
environment anyway...
>Anyway, RBIL contains many functions which are not actually
>callable as interrupts and are only using internally; even
>the DOS kernel uses similar techniques in some of its internal
>interfaces.
>
In effect, all Geos API run through the "overlay" scheme I described:
when a Geos application is loaded into memory, the loader will
automatically replace calls to functions in the system libraries by the
corresponding INT-based calls. Anyway, these are not constant, but
depend on the handle assigned to the library's code segment.
This is actually much more similar to Windows DLLs than to the way DOS
programs call APIs (either through definined INT vectors or through
dispatcher entry points that are retrieved via an INT first).
As for the Geos installation check you describe, I am not sure. I'm not
aware of any... Gene? :-)
ciao marcus
Jens-Michael Gross
answers)
Matthias Paul schrieb:
>
> Hi GEOS/NDO programmers,
>
> I am preparing some stuff for the forthcoming Ralf Brown´s
> Interrupt List 62
I love this list. Unfortunately I only got a set with a damaged ZIP
file, and later I couldn't find a non-HTML-version. But I didn't really
try.
It has been very helpful in the past for smaller problems when working
for DOS and GEOS.
> and just checked that there is not a single mentioning
> of PC/GEOS or New Deal Office in the list so far...
Actually, there is nothing that GEOS does to the interrupts which could
be detected or used by any DOS program.
While GEOS changes some interrupts (including 80-8f), all these changes
are undone when launching a DOS program (GEOS then shuts down and leaves
just a standard loader for reboot after the DOS program exits) or
switching to a DOS program using TaskMax/TaskMgr (then the task manager
will restore all vectors to the status when the task manager has been
installed).
So no reason to mention GEOS in the list.
It _could_ be of interest for GEOS programmers who want to access DOS
interrupts from within a GEOS program. This should only happen in
drivers and there are only a few people who have ever written a GEOS
driver at all (including me, Ed and Marcus, who already answered to your
question)
> OK, GEOS is an OS environment in its own, but there are
> certainly some special interactions with the host operating
> system DOS, which should be documented in RBIL.
All of these interactions are going only _from_ GEOS _to_ DOS.
> This info
> might be very important for programmers of DOS device
> drivers (say, some keyboard drivers or screen savers)
> or even alternative DOS kernels such as FreeDOS.
Maybe - TSR using INT8x wouldn't work while GEOS is active. And
interactions between two TSRs through INT8x would probably crash the
system. But this is an unlikely scenario.
> - I am not a GEOS programmer myself (yet ;)
You're welcome if you want to join. It's a real experience (in more than
one meaning). But it would definitely open your eyes about the puniness
of Microsoft windows programming - unless you plan to become a simple
wizard-clicker in VB or VC++.
> but if its
> programming model is interrupt or far-call drivern,
> there certainly is a place for it in RBIL, either in
> INTERRUP.LST or in FARCALL.LST.
It is completely interrupt-driven (as already explained by Ed and
Marcus).
It would have been easier if the far call instruction could be set to
cause an exception :)
But since the whole code is (with a few, more accidental exceptions)
8088 compatible, the whole system uses simple assembly methods. This is
the reason why it works under linux Dosemu, Mac PC emulator and more or
less all windows versions.
> - Is there something like a startup/shutdown broadcast
Not that I'm aware of. GEOS checks for the presence of TaskMax/TaskMgr
when loading the DOS task switch driver (which in absence causes a
temporary shutdown for DOS program launch) and also for MSCDEX, XMS, EMS
and the DOS version when loading the memory and file system drivers,
also for a VESA BIOS when one of the VESA video modes is installed, but
it doesn't behave other than normal DOS programs.
I believe that GEOS is installing itself as task managing UI if TaskMax
is present (so switching tasks will call GEOS and the GEOS task menu
instead of the normal text mdoe task menu) but I think that's all.
> Similar, is there a broadcast issued, when GEOS/NDO
> fires up DOS tasks (with or without the DR-DOS TASKMAX/
> TASKMGR)?
With, it is done through the Taskmax API, without, it is done by
shutting down GEOS with just a bootstrap loader below the executed
program. Even EMS/XMS memory is freed and all files are closed.
The GEOS document and application state model allows shutting down and
restoring system configuration at next startup, including open dialog
windows and exact window positions and even the text cursor where it was
at shutdown time.
> If there are are no such broadcasts, I think it would be
> very important to add something like this in a future
> version (in case there will ever be one), even if they
> have not been needed so far.
It would be of interest as soon as GEOS ould add the functionality to
m,ultitask DOS tasks in a DOS window (as in Windows). But currently,
there is no need. GEOS is just another DOS program and way less
complicated (for the outside system) than any DOS program using Dos4GW
or such.
> - Is there an installation check interrupt, which could be
> called by DOS drivers to see if and which version of
> GEOS/NDO is currently running?
Not really, but you could check whether the INT8x point all to the same
place :)
> - Apparently GEOS/NDO or at least its drivers have intimate
> knowledge of the underlaying DOS disk subsystem, hence all
> these different DRI.GEO, MS3.GEO, MS4.GEO drivers.
Actually, there are only minor differences about buffer sizes, maximum
pathlengths and so on. Most of the work is done by DOS. But as an OS, it
should intercept possible error due to file system limitations before it
gets back an error from DOS.
Partly because some DOS versions tend to print a text 'abort, retry,
ignore' dialog onto the graphics screen and wait for a keystroke while
there is no keyboard available to DOS at all. :)
> Does
> someone know, which specific values, structures, or
> interrupts GEOS/NDO relies upon, so that the FreeDOS
> developers could take care of that these criteria are
> met, so that GEOS/NDO runs there as well. Similar for
> other drivers.
I don't know the interrupt numbers, but of course the standard DOS
interrupt for all file handling, the multiplexer interrupt (for MSCDEX
and network drives), Video bios calls (including VESA Bios), LPT and COM
BIOS calls (if configured) as well as the hardware interrupts for these
ports, mouse (com or PS/2 or installed DOS mouse driver, depending on
configuration) and the TaskMgr API, including the (in TaskMgr defunct,
but in TaskMax working) text clipboard calls (I love this feature).
My Scanner driver uses the device driver request for getting the entry
point of the ASPI driver for SCSI scanners and my CD player uses MSCDEX
and through it the cdrom driver calls.
And I still have my USB project on schedule list which might have a DOS
and GEOS part in its first implementation.
I forgot the interrupt and DMA access for sounblaster compatible
soundcards.
> - Are there any known bugs (even already fixed ones),
> limitations, workarounds, or usage quirks, which may
> affect the host system, say, the usage of the BIOS
> data area in segment 40h or a work around for a bug
> in a DOS device driver, which GEOS/NDO relies upon?
There was a problem with NWCDEX when the CD drive was accessed but no CD
inside. This caused DOS to print an error message (garbage on the
graphic screen) and wait for a keypress that could never come. MSCDEX
worked, because the cdrom file system driver knew the stupid 'internal
error' of MSCDEX, but not the correct 'drive not ready error' of NWCDEX.
I think this has been fixed in the latest release by Ed, but his fix
doesn't work on Version 2.x, only 3.x and 2000.
> I found GEOS/NDO to be very limited in its use of COM ports,
> as - astonishing enough for a program developed in the 1990th -
> it does not appear to use the port addresses for the serial
> ports provided by the system BIOS and DOS in segment 40h.
Yes, the setup shouldn't read 'COM1", but 'COM port on 3e8h' and so on.
I guess it has been hardcoded to make the code run faster. Making
configurable calls on an XT would make every COM access more than
sloooow. :)
> So far I was not able to use my modem, which is on COM4 configured
> to an I/O address of 260h with IRQ 9 instead of the standard I/O
> address 2E8h/IRQ 3 (which would be conflicting with modern video
> cards).
Known issue. S3 ( I think it was S3) didn't decode enough address lines
to separate 02e8h from 12e8h. Definitely a big bug on the S3 graphic
chips.
> Four COM ports and the address of 260h are correctly set up in
> the BIOS segment 40h, and other DOS and Windows modem software
> can use this without any problems, but GEOS/NDO refuses to use
> this info.
The original drivers used teh IBM specification way too often (and
others have ignored the specs way too often).
Same for the original soundblaster drivers, which always used IRQ 7. The
new ones now check the BLASTER variable.
> I was able to find the hard-wired addresses in some of the
> GEOS drivers like SERIAL.GEO, HPREFCN.GEO, and PREFCOMP.GEO
> and patched them to 260h, and it accepts the port settig now.
hprefcn? I think this is the serial HP printer driver or so.
Serial.geo is the place that counts.
> However my UART uses IRQ 9 (which is /not/ used by the video
> card on my system, and I cannot change this, as all other IRQs
> are in use already), but NDO 3.2A always falls back to 7 when
> I select 9 in preferences, so the port is still not useable,
> and I have not yet found a way to patch this as well. Anyone?
Maybe you can directly manipulate the GEOS.INI. The actual interrupt
should be defined there. It's of course possible that serial.geo rejects
settings it considers wrong.
High interrupts (8-15) have been a problem in older versions anyway, as
the driver didn't handle the stacked interrupt chips correctly. (not
setting back INT2 after the high int has been handled)
> Hence, do you know of similar quirks in other places?
Lack of skilled programmers? :)
> If the info you can provide would be too large to be posted here,
> please feel free to contact Ralf (or me) directly, so that it can
> be included in the forthcoming issue.
Here is so much traffic recently, that the net will surely break down if
we answer your post in the newsgroup :)
Grossibaer
Matthias Paul
> 2. The Geos linker turns this into something else:
>
> INT 8xh -> CD 8x
> DB <seghigh>,<offlow>,<offhigh>
>
> [Note: without additional research, I can't guarantee for the exact
> order of the three data bytes.]
I think this is worth including it in RBIL, can you check the order
of the data bytes, please?
> The interrupt handler for all those vectors is the same. It will
> "unpack" the adress from the three-and-a-half byte notation, look up the
> absolute address of the segment, and forward the call, after having done
> its virtual memory loading thing... Return from the call will also pass
> through the corresponding unlocking code.
>
> It also implies that Geos performance is critically dependent on good
> EMM386 performance (because of interrupt latency), and that FAR jumps
> are unusually expensive.
That´s a nice concept, but given all the overhead it´s really expensive...
I know way too little about GEOS´ inner workings, but at least at
a first glance it seems to me as if it would have been possible to
create a similar (though a bit dirtier) solution, which would have
worked with dynamically fixed up far calls and local dispatch tables
instead of interrupts, so that it would have been possible to avoid
the use of actual interrupts...
Well, the GEOS designers probably had good reasons to do it the
way they did... ;-)
Greetings and thanks alot,
Edward Di Geronimo Jr.
> On 2002-0224, Marcus Groeber wrote:
>
> > 2. The Geos linker turns this into something else:
> >
> > INT 8xh -> CD 8x
> > DB <seghigh>,<offlow>,<offhigh>
> >
> > [Note: without additional research, I can't guarantee for the exact
> > order of the three data bytes.]
>
> I think this is worth including it in RBIL, can you check the order
> of the data bytes, please?
That order is right.
Ed
Jens-Michael Gross
> I know way too little about GEOS´ inner workings, but at least at
> a first glance it seems to me as if it would have been possible to
> create a similar (though a bit dirtier) solution, which would have
> worked with dynamically fixed up far calls and local dispatch tables
> instead of interrupts, so that it would have been possible to avoid
> the use of actual interrupts...
> Well, the GEOS designers probably had good reasons to do it the
> way they did... ;-)
The genial effect of doing it the way GEOS does it is that you'll have
v86 mode virual memory without processor support (remember, GEOS works
on a plain XT, so no 16bit or 32bit protected mode for memory handling).
Also, using fixed-up far calls would need the libraries loaded on a
fixed position until the program releases them. GEOS can swap them
dynamically in and out as memory needs direct. And additional local
dispatch dables would waste memory for the tables and cycles for the
follow-up jump.
When you look at the Windows memory managing, you'll see that it works
the same way GEOS does, but wit the difference that the interrupt call
isn't coded into the jump, but indirectly done as an exception when far
cal hits the void. It's the same basic idea, but without the memory
exception support on processor level, which was unavailable on XTs.
Of course if you cascade both (by running GEOS under emm386 or windows
VMM32) things slow down additionally.
anyway, even with sloooow interrupt handling, GEOS is still faster than
any comparable windows software on the same machine :)
Grossibaer
Marcus Groeber
>>2. The Geos linker turns this into something else:
>>
>> INT 8xh -> CD 8x
>> DB <seghigh>,<offlow>,<offhigh>
>>
>>[Note: without additional research, I can't guarantee for the exact
>>order of the three data bytes.]
>>
>I think this is worth including it in RBIL, can you check the order
>of the data bytes, please?
>
As Ed already wrote, I happened to guess right. :-)
The low nibble of the interrupt vector (80h-8Fh) holds bit 4 through 7
of the segment handle. Bit 0 to 3 of a segment handle are (by definition
of a Geos handle) always 0.
>I know way too little about GEOS´ inner workings, but at least at
>a first glance it seems to me as if it would have been possible to
>create a similar (though a bit dirtier) solution, which would have
>worked with dynamically fixed up far calls and local dispatch tables
>instead of interrupts, so that it would have been possible to avoid
>the use of actual interrupts...
>
The downside of such an approach would be that the dynamically fixed up
far calls would have to be updated whenever a segment moves in memory
(which is frequently the case while a segment is not on the call stack).
If a code segment is discarded, it would even become necessary to
replace the call by a reference to a "thunk" that knows how to reload
this particular segment.
Another aspect of this is that Geos was originally intended to be
converted to protected mode very early on (i.e. ten years ago), with
real mode only being a "legacy option" (similar to the treatment of
real/standard mode in Windows 3.0). Unfortunately, this never happened,
but almost every single line of assembly code is ready for it, which is
why the idea has been coming up again and again for the best part of a
decade now on comp.os.geos. :-)
ciao marcus