From: "John M. Aldrich" Newsgroups: comp.os.msdos.djgpp Subject: Re: unsigned char *far : problems Date: Wed, 04 Dec 1996 01:10:55 -0800 Organization: Three pounds of chaos and a pinch of salt Lines: 33 Message-ID: <32A5401F.3FA2@cs.com> References: <01bbe146$95359e20$582449c2 AT default> Reply-To: fighteer AT cs DOT com NNTP-Posting-Host: ppp101.cs.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Thomas Harte DJ-Gateway: from newsgroup comp.os.msdos.djgpp Thomas Harte wrote: > > I have just moved over from a 'friendly' Microsoft compiler, and have tried > compiling some old problems, but it (v2.01) won't compile with the > following lines:- > > unsigned char far *videobuf = (char far *)0xA0000000L; > unsigned int far *videobufw = (int far *)0xA0000000L; You are experiencing one of the fundamental problems that many people have when switching from a real mode compiler to a protected-mode compiler; things just don't work the same way. In DJGPP, there _are_ no segments; thus you don't need far pointers or MK_FP or any of the other nasty Borland-isms you are used to. However, because memory is "protected", you can't just directly access the video RAM either. Please download and read the DJGPP Frequently Asked Questions list (v2/faq202b.zip) from the same place you got DJGPP. Chapters 10, 17, and 18 specifically deal with the issue of converting real mode graphics programs into protected mode. It's a lot more complicated than just finding a substitute for 'far'. -- John M. Aldrich * Anything that happens, happens. * Anything that, in happening, causes something else to happen, causes something else to happen. * Anything that, in happening, causes itself to happen again, happens again. * It doesn't necessarily do it in chronological order, though. --- Douglas Adams