From: "Andrew D. Jones" Newsgroups: comp.os.msdos.programmer,comp.os.msdos.djgpp Subject: Re: Porting DJGPP DPMI Apps-->Borland C++5.x Message-ID: <7d2f3t44fjl4sb98qt42tectb54qoc9d0v@4ax.com> References: <3A302D69 DOT 8020107 AT home DOT com> <3A36A472 DOT 7040003 AT home DOT com> X-Newsreader: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 53 Date: Wed, 13 Dec 2000 14:44:01 GMT NNTP-Posting-Host: 24.43.195.250 X-Complaints-To: abuse AT home DOT net X-Trace: news3.rdc1.on.home.com 976718641 24.43.195.250 (Wed, 13 Dec 2000 06:44:01 PST) NNTP-Posting-Date: Wed, 13 Dec 2000 06:44:01 PST Organization: Excite AT Home - The Leader in Broadband http://home.com/faster To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Tue, 12 Dec 2000 15:19:30 -0700, Russ Magee wrote: [snip] >1) If we use the 5.0 compiler and make 16-bit DOS apps, is it true we don't >need DPMI at all, and can just call BIOS the traditional way, and bang >on hardware directly? Bang away! DPMI is only required for protected-mode (DOS) programs as an interface to the real-mode DOS operating system (and system BIOS) on which it runs. Not having to make calls through DPMI would actually simplify your programs (no more need to call DPMI Simulate Real Mode Interrupt, you just fill the registers and such and call the interrupt yourself.) On the other hand, you lose the flat address space, and have to start worrying about segments and such. >2) If we use the newer compiler, and compile win32 console apps, can these >access the BIOS and hit hardware directly as well? If so, does it look >the same from the assembly-coder's standpoint (other than being able >to use a flat address space, I suppose, which would be nicer)? The >textbooks on PC Assembler/Hardware Architecture all use DOS apps in their >examples of accessing hardware/BIOS directly. We NEED the development >environment to be somewhat compatible with the textbook. AFAIK, Win32 (GUI/console) programs cannot access the underlying hardware themself. You would need to write VxD's through which your main program would access the hardware (the other side of that is that you could use the existing Win32 API calls, but I don't think that fits into what you have in mind.) >3) And can we use VESA BIOS calls with either of the above schemes, without >DJGPP? (IE, what kind of support for VESA calls is there in TASM, Borland >C/C++)? You seem to be a bit unclear about these things. If your program runs in DOS, no matter whether it's in real-mode or protected-mode, it can access the VESA BIOS Extensions. It's just a matter of how to do it. TASM/BC++ itself doesn't "support" VESA. You write the code to do it yourself. :) Although, I'd recommend using NASM over TASM, but that's just my own opinion. :) >I hope this is clearer. Thanks again in advance, And I hope this helps a bit more. -- Andrew Jones