Mail Archives: djgpp/1996/10/22/02:25:00
Georg Viehhauser wrote:
>
> Dear Gurus,
>
> We have bought recently a multichannel analyzer card for one of our
> 386s. Now I would like to write some software to read out this card.
> Together with the card they shipped a demo program (source code and
> executables). The executeable works fine. They quote that the executable
> was obtained using Turbo C++.
>
> I modified the program and want to compile it withg djgpp, but he tells
> me that he cannot find the file alloc.h. If I remove the #include
> <alloc.h>, he compiles, but stops during linking with a number of
> undefined references, which I guess are defined in alloc.h:
>
> richgain.cc(.text+0x19b): undefined reference to `farmalloc'
> richgain.cc(.text+0x5cd): undefined reference to `peek'
> richgain.cc(.text+0x5e5): undefined reference to `peek'
> richgain.cc(.text+0x603): undefined reference to `peekb'
> richgain.cc(.text+0x67b): undefined reference to `MK_FP'
> richgain.cc(.text+0x694): undefined reference to `movmem'
> richgain.cc(.text+0x72d): undefined reference to `FP_SEG'
> richgain.cc(.text+0x742): undefined reference to `FP_OFF'
>
First off, these are 16-bit real-mode instructions and it will take some
work to get your code working.
First place a
#define far
somewhere in a generally accessed header to get rid of all the "far"'s.
Then
#include <malloc.h>
and change farmalloc to malloc.
peek,peekb,poke and pokeb become farnspeekb,farnspeekw,farnspokeb and farnspokeb.
Use info for more information or read the header files in include/sys/, or the FAQ.
MK_FP doesn't exist; it stands for MaKe FarPointer and there are no far pointers
in djgpp. If you are passing an absolute address to MK_FP, remove the MK_FP,
add a zero (ie 0xa000 becomes 0xa0000), check all functions using that pointer,
call __djgpp_nearptr_enable(), add __djgpp_set_conventional_base to the pointer
(ie ax0000 + __djgpp_set_conventional_base ), and hope for the best.
Not the safest option but it works sometimes.
Depending on the context, try to replace movmem with memcpy, movedata or
dosmemput (check info for details on these functions).
Functions using FP_SEG and FP_OFF are also courting disaster; your best bet
is to check the parts using them,and try to replace the dual occurrences of
FP_SEG and FP_OFF with one single pointer consisting of whatever FP_OFF
and FP_SEG were trying to separate. If absolute adresses in real memory
were being addressed this will likely fail anyway.
It's difficult to say offhand without seeing the code which changes precisely
have to be made, and which will likely fail without further hacking ( accessing
absolute adresses in real-mode is one of them: in p-mode things just aren't
sitting where you'd expect them to be in real mode -- like font addresses,
video memory, etc etc); changing the syntax and eliminating far pointers
doesn't mean that your program will neccessarily run.
Set an evening aside, print out the FAQ , grab a thermos
of your favourite poison, start your computer, and try converting it.
Luck,
Elliott.
- Raw text -