Subject: Microsoft progress + idea

From: [email-masked]
Date: Fri, 11 Dec 1992 09:05:39 +0100

I've been working the last few days to get R386 (more specifically the DEVEL4
package) to work under microsoft C.

Here are a few inputs:

#include <alloc.h>    -> malloc.h
#include <str.h>      -> string.h
outportb -> outp
outport  -> outpw
inportb  -> inp
disable  -> _disable
enable   -> _enable
bioskey  -> my own function using _bios_keyboard
delay    -> my own function
geninterrupt -> int86
MK_FP    -> write function

One thing to watch out for particularly, is that non-microsoft C malloc's are
always normalized, e.g. as much as possible is in the segment part and as
little as possible in the offset (never more than 15). This is NOT true in
microsoft, and malloc() is happy to return 0x2178:0x3192 to me. THIS FUCKS
UP DRIVER LOADING PRETTY BAD :-)

(Btw, isn't there a bug in the fread() in driver load, shouldn't the 16 be a
1? Or if I am not mistaken, you try to read 16 times the file size?)

I also had to recompile all sources NOT having _asm in them, since Microsoft
(I am using 7.0) does NOT do 386 inline assembler. I have also not touched the
.ASM files themselves.

Some things seems to need to be declared near, like the sintable, tantable,
and the v_driver_pointer.

Question: SHould the whole damn program run in what memory model? Medium or 
Large? I use Large.

The progress so far:

Using OLD code (e.g. devel2.zip) I managed to get something semi-running:
I can spin cube.plg for about 3 frames, but then it crashes with a division
by zero error. The cosine lighting looks totally wrong too.

Using NEW code (e.g. devel4.zip) I am yet to get something on screen. It
crashes with Out of Stack space (although I've pumped up the stack to
40000 bytes!) at places where it really CAN'T do it.... I suspect it actualy
is the DEBUGGER that crashes with out-of-stack-space...?!?!? (Codeview).

I also have access to TurboC (but *not* TASM!) 2.0 i think. WOuld this be
an easier route to be able to compile something of my own?

I'll keep you dudes informed. Happy for ANY info.

/Z/Z/Z

---

From: [email-masked] (Shannon Posniewski)
Date: Fri, 11 Dec 92 9:31:55 EST

> UP DRIVER LOADING PRETTY BAD :-)

Yup, that's true.  On a segmented architecture, two different far addresses
might actually addres sthe same location.  (one of its beauties as well
as one of its foibles.) You have two options:

1 - declare the pointer as "huge" instead of "far".  This tells the compiler
    to generate code like you described.  In addition, however, extra
    overhead is induced every time you manipulate the pointer.

2 - Use the following code fragment to "hugeify" a far address.

char far *hugeify(char far *ptr) {
	char far *p;

	FP_SEG(p)=FP_SEG(ptr)+FP_OFF(ptr)/16;
	FP_OFF(p)=FP_OFF(ptr)%16;

	return(p);
}

> (I am using 7.0) does NOT do 386 inline assembler. I have also not touched the

You'll have to pull the inline assembly out into a separate .asm file.

> is the DEBUGGER that crashes with out-of-stack-space...?!?!? (Codeview).

I haven't looked deeply at the code, but I suspect that traversing the 
object tree could be quite stack intensive.  40K isn't completely out of hand.
Don't run in CV and see if that's the problem.  Also, look for the _stklen
variable source.  Borland/Turbo C uses that to change the stack size.

> /Z/Z/Z

Poz