From: Elliott Oti Newsgroups: comp.os.msdos.djgpp Subject: Re: Need Help: Where can I find ? Date: Mon, 21 Oct 1996 12:46:23 -0700 Organization: Academic Computer Centre Utrecht, (ACCU) Lines: 62 Message-ID: <326BD30F.1A61@stud.warande.ruu.nl> References: <326BA883 DOT 41C6 AT suhep DOT phy DOT syr DOT edu> NNTP-Posting-Host: warande1078.warande.ruu.nl Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp 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 > , 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 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.