cm@jet.uucp (colin manning) (04/09/91)
Good afternoon/afternoon/evening netters ! I have several questions concerning programming in 386 protected mode. Does anyone have any experience of either the Intel 386 C code builder, or the (significantly more expensive) Watcom C8.0/386. Any feelings for reliability, quality of support etc ? What produces the best code ? Or should I be thinking of something totally different ? The requirement does not necessarily need a DOS extender, just a protected mode environment, since the application will never have any need to use DOS facilities itself. Do any of the above or other 386 development tools available provide such a thing, or do you always need a DOS extender ? It is possible to do interrupt handling in protected mode with either of the above kits, or do they still hand all that on to the DOS extender ? Many thanks in advance, -- - Colin Manning, cm%jet.uucp@ukc.ac.uk (world) OR cm@jet.uucp (UK only) ------------------------------ Disclaimer: Please note that the above is a personal view and should not be construed as an official comment from the JET project.
dj@bragi.ctron.com (DJ Delorie) (04/10/91)
In article <1991Apr9.141613.26291@jet.uucp> cm@jet.uucp (colin manning) writes: >Does anyone have any experience of either the Intel 386 C code builder, >or the (significantly more expensive) Watcom C8.0/386. Any feelings >for reliability, quality of support etc ? What produces the best >code ? Or should I be thinking of something totally different ? I recently ported gnu C++ to 386/DOS protected mode. It should be posted on comp.binaries.ibm.pc soon-ish (it's big). The price is right and the compiler is well known to produce good code. As for support, you get the source code! For those with FTP access, it's in grape.ecs.clarkson.edu in ~ftp/pub/msdos/djgcc/... (get the `readme' first and read it). >The requirement does not necessarily need a DOS extender, just a >protected mode environment, since the application will never have any >need to use DOS facilities itself. Do any of the above or other 386 >development tools available provide such a thing, or do you always >need a DOS extender ? You always need a DOS extender at least to get it running. Mine runs the application in ring 0, so there's nothing stopping you from grabbing the IDT, GDT, PD, etc and never returning to the extender at all . . . >It is possible to do interrupt handling in protected mode with either >of the above kits, or do they still hand all that on to the DOS >extender ? Mine has no built-in facility for grabbing interrupts, but you can always do a LIDT instruction and change the interrupt vectors in assembler to point to interrupt handlers that run in 32-bit mode. DJ dj@ctron.com
wallyk@bicycle.WV.TEK.COM (Wally Kramer) (04/11/91)
In article <1991Apr9.141613.26291@jet.uucp> cm@jet.uucp (colin manning) writes: ... > Does anyone have any experience of ... the Intel 386 C code builder ... ? ... About 3 years ago I worked on a project using the iNtel 386 tools. To summarize, they are awful. It wasn't just bugs, but major architectural flaws. As for support, .... Want me to say it again? :-) The saleman showed up weekly however (we were literally across the street from the division of iNtel which developed it). No bug I knew of was fixed throughout the 5 month period. The ICE was just as bad. To provide a semi-balanced opinion, the project did complete successfully. I'd hope they've fixed the major shortcomings, but, as I said, there were some architectural flaws: - To produce an executable from object modules required at least two steps, a binder and a builder (I think that's what they were called); one of these was extremely slow, and used so much memory that the network could not be simultaneously loaded. The steps to do a test iteration: 1. modify source code 2. compile it 3. update libraries (on the net) 4. copy updated libraries to local disk 5. reboot machine without network loaded 6. run the binder 7. run the builder 8. reboot with the network loaded 9. copy the result to the net, where the ICE could download it 10. run the simulator. As I recall, for ~400k of executable code, this was a 2-3 hour process. - At the time, the object module format was "proprietary". No third party binders & builders. (Is this still true?) - The documentation was below average. Poorly organized, omitted details and useful examples at every turn. - The ICE searched its symbol table for every piece of the command line. They had omitted any "modern" technique for speeding this search up. I don't remember specifics now, but, for example, placing a breakpoint at procedure foo and running required something like this: go foo With our build, it would take something like 45 seconds for the command to be parsed and about 1/4 second to execute. (That's what I call *real time*!) ----- Wally Kramer contracted from Step Technology, Portland, Oregon 503 244 1239 wallyk@orca.wv.tek.com +1 503 685 2658