I''m trying to learn how do develop something for a different OS than Windows and Linux, and the first step is compiling the example code that comes with it. The code itself is being compiled on my windows PC, and it''s giving me problems with far pointers: char far * name; error! so how can I solve this, since this is example code I''m pretty sure that I can''t take out all of the fars. If you can help me in either VC++ or Borlands please point me in the right direction, thanks

Far pointers are a throwback to 16bit addressing. To access memory over 64k a segment and offset were required. The segment was the id of the 64k block, and the offset was the pointer to an address within that block.

The Win32 API requires all pointers to be 32 bit, removing the need for segment:offset addressing so you can remove all the fars safely so long as none of the remaining code expects pointers to be 16 bit - e.g. if the program mallocs enough memory for X number of 16bit pointers, or copies the contents of one pointer to another specifying a pointer size of 2 bytes.

You''ll need to look out for those cases, but properly written code should be fine - it depends how old it is too.

Cheers

Matt

But that''s the problem, this code isn''t meant to run under Win 32 conditions, its meant to run under a (presumably) 16 bit OS, an OS that probably nobody''s heard of since it''s just some companies custom OS for their weird machine. So how can I get this code to compile (it needs the fars)

You''re trying to compile on a windows machine for a non-windows target? Does that even work? Maybe I''m misunderstanding.

If you have far and near as necessarily different byte codes in your target OS, then you should be using a compiler that understands how to build to that target and will generate the appropriate code. If you''re trying to convert a program that used to work on a different OS to work with windows, you can just remove the far/nears.

The 16-bit compiler I''m using has @far (as in char @far *ptr), but you could also try _far and __far.

Failing that, try looking in the compiler exe file with a hex viewer - see if you can see any other combination of far or huge.

Huge pointers were something Borland used back in the good old days - but their implementation of huge was slower than far, and also behaved differently. (Huge pointers could be incremented across segment boundaries, but far pointers wrapped back to offset zero).

Well, the OS I''m compiling for is a custom OS, you can''t run any compilers off of it or anything. But I''m sure that you can compile the software off of Borlands and MSVC++, because here are the compiling instructions included with example code file:

1.For Borland C compiler users: *
* - Use Borland C++ V4.5/4.52 to compile this C source code to generate *
* a .obj file; *
* - Use TLINK.EXE to generate a binary file similar to .COM format; *
* - Use BIN2HEX.EXE to convert the above generated file to an Intel Hex *
* format file downloadable to AWC86/86A. *
* *
* 2.For Microsoft C compiler users: *
* - Use Microsoft VC++ 1.00-1.52 to compile this C source code and *
* generate a .obj file; *
* - Use LINK.EXE to generate a binary file similar to .COM format; *
* - Use BIN2HEX.EXE to convert the above generated file to an Intel Hex *
* format file downloadable to AWC86/86A. *

Uhmm...if you look at the version numbers of both Borland C++ and VC++ you will realize that these are old 16 bit compilers. Newer versions of these compilers don''t compile to 16 bit code at all. You might want to check out the Museum section of Borlands website, though. I believe they have an old version of TurboC++ in there somewhere.

I realy dont'' wanna use VC version 1 (that must be at least 5 or 6 years old.) But if I use the old borlands compiler I''ll be able to run and compile under windows 98 right?

you should be able to compile the code on win98, but if it''s for another OS than windows or dos, it won''t run!

one thing to look out with with old borland compilers is that sometimes they don''t allocate enough memory when you ask for it with new, I don''t know about using malloc() though. That problem caused me hours of greef, upgraded the compiler, no problem

-arsenius
''after three days without programming, life becomes meaningless'' -The Tao of Programming

Well, if you don''t want to compile it with an old 16-bit compiler, stick a
#define far
somewhere at the beginning of the code.