Warum rebootet BP7 meinen PC (hat 224 MB RAM) wenn ich es von Plain DOS
7.x aus starten will?

Gru?

                             Requirements:

  - i386 or better processor
  - more than 1MB memory installed
  - pure DOS (not Windows, without memory managers listed above)
  - you should program in assemler language, if you want your program
    runs fast, because pascal routines are too slow

                                            Author: Alexei A. Frounze

E-mail: alex...@chat.ru
Homepage: http://www.chat.ru/~alexfru
<======== ========>
3) with XMS 2.0 functions you can work with a number of handlers by (up to)
64M for each

*  In protected mode (with RTM.EXE) I didn't work but I here about utility
RTMSWAP (or so) that able to add swaped-memory (from disk of course) to
64M-barrier

- I need DLLs, so I need DPMI (BP's DPMI provides DLLs and there is some
   "hack" for 321 bit as well but with that {*word*193} 64 MB limit)

- the program shall run under Extenders or Windows 9x to avoid
   complicated configuration or reboots for the user...

But: thanks anyway!!

Greetings

Greetings

Here is the solution:

http://mr_monett.tripod.com/frm.htm

BTW, the built-in DPMI server from DR DOS 7.03 is buggy - don't use it.

--
Jay

I need DLLs for dynamic drivers and I don't like to throw away that
widely supported concept for something selfmade which wouldn't have that
acceptance then. My program shall be multilanguage: C and BP DLLs shall
be possible...

Greetings

supports the mouse wheel on PS/2 ones...I tried it already and it works! Included is the wheel API documentation!

Great stuff!
Wouldn't that be nice for GV too?

If yes, why not ask Borland to release it?

Greetings

When you talk about DLL's I assume you mean the ones used with
Windows.

Yes, Flat Mode has no DLL support. The cpu is running in real mode,
and it cannot execute code above 1meg due to the 16-bit stack. Alexei
Frounze briefly mentioned a technique of remapping memory in clax to
make blocks of addresses above 1 meg appear to start at zero, but this
would be tricky to implement and would not work with DLL's larger than
1meg.

My problem with DLL's is the "DLL Hell" in distribution. You have to
include each DLL used with your code to ensure everyone has a copy of
the version needed by your software.

After a while, your distribution ages and becomes down-level. Users
end up with multiple copies of the same DLL scattered on their hard
disk, which can cause no end of headaches since they do not know which
one is correct.

If you do not distribute the DLL with your code, you have to check
every version of code that was ever released to ensure that someone
does not install a copy that contains a bug that kills your code. This
is an  impossible task.

Another problem with DLL's is you really have no idea what is in them,
unless you happen to have the source code. So you have no way to tell
what kind of problems might occur with different combinations of
hardware and software, and you have no way to correct any problems
that might occur. If your goal is to produce software that will be
widely distributed, it might be better to write your own drivers so
you know what is in them and can solve the myriad problems that users
will have with different hardware configurations.

I'm not sure including DLL's would give your code wider acceptance.
Many people are familiar with the problems they cause, and may be
reluctant to use your code when they see that you depend on them. I
know I get very suspicious of code that assumes I will have some
needed component on my hard disk. I prefer code that is completely
self-contained, because it tells me the author has taken the trouble
to ensure his code will work no matter what version of DLL I may have
on my disk.

If I am mistaken about your intended use of DLL's, please let me know.

The EMM386 problem is solved with the alternative versions discussed
in my article. I found it causes a 50% drop in hard disk performance
due to the multiple translations between EMM386 and Himem. I rarely
use it, but I'm sure many people depend on it since it also provides
more memory for DOS.

My DLLs are no Windows DLLs but 16 bit DOS DLLs (which are indeed
possible with BP7 and some C compilers). My project shall be extensible
by other programmers not directly belonging to it. The necessary API
will be described and explained somewhere on the net and there will be
SDKs then (if my project ever comes so far). Each of the DLLs for my
project must have some defined functions to return the version number of
the DLL, the version of the main programm the DLL needs, the CPU it
needs, whether it needs a FPU or FPU emulation, the language of the
messages included in the DLL etc. so my main programm (and some little
utility supplied with it) can read this information and act acordingly.
The DLLs won't be spread over the whole HDD too, because they only
belong to my app. and not to Windooze. I hope you see clear now about my
intention to use DLLs. And since such DLLs are "relatively" cross
compiler among PASCAL and C I think this would help the support through
external programmers most.

Greetings

I assume you intend to supply binaries, and each programmer will use C
or Pascal as desired. Can you debug a DLL by simply loading the source
in the de{*word*81} and setting a breakpoint at the desired location? My
guess is it should work fine in C if the OBJ file is compiled with
debug info.

Do you plan on making the source for the DLL's available? What happens
if there is a bug and the owner of the DLL has lost interest or moved
to a deserted island?

Yes I know, I helped write it!  (look in the CuteMouse credits) :-)

CuteMouse-style wheel support will be in the next official release of GV
(version 2.30), to be announced in the next 2-4 weeks.

--
Jay

You ask! :-)

There may be one more problem - The DPMI server/extenders were not written by
Borland, they simply bought or commissioned them from Ergo.

--
Jay