[comp.os.os2.misc] Rumors

Steve_Lesner@f170.n771.z3.fidonet.org (Steve Lesner) (05/19/91)

 PO> I fully agree! The closer you tie a software package to the hardware 
the 
 PO> better the peformance will be. In the case of video it can be orders of 
 PO> magnitude.

I totally diagree.  If it wasn't for the portable code that many DOS authors 
wrote, we wouldn't have jack shit for OS/2 programs now!

 PO> The nice portable C function of fopen() adds better than 2K of program 
 PO> code. The system call   DosOpen    adds around 10. 

Who cares nowadays?  Are you saying I should whip out my old Wordstar Ver 1.
0 and run under 64k memory?  Lets get real, code is going to be large 
nowadays and thats why systems like OS/2 break out of memory and system 
restraints.
Besides, most all of the OS/2 source code I've seen uses Dosopen.  One of 
the reasons I haven't started porting many of these famous DOS WWIV BBS 
games to OS/2 is because the code is too damn dependent on interupts, 
specific dos functions that only run under dos such as msdos(irq, regs), etc.
Its a real nightmare, some of this stuff, that I just as soon start from 
scratch!

 PO> Using a GOOD video card and a 386 you can redraw the screen in about 
8000 
 PO> clocks. Using a DosWrite its in the area of 50,000,000, and I shudder 
to 
 PO> think what a putchar() would do to it.

I do agree here but again, portability goes out the window.  I too have been 
noted for bypassing standard dos calls and writing to the hardware.  But I 
think that that solution too, is not good.  What we need is some sort of 
mechanism to write to hardware in a portable way (which in itself is a 
conflict in terms).  I understand the issue of screen speed.  But I also 
understand the need to port.  Many unix apps were written with the video 
routines in separate modules.  This is a good idea as all an OS/2 
programmerneeds to do is the replace that module alone.  If the other 
modules are written with portability in mind (like many unix programmers do 
automatically),the world of programming would be a hell of a lot easier.



--- Maximus-CBCS v1.02.OS/2.B0
 * Origin: Uh Huh, OS/2, I've got the right one Baby, Uh Huh (1:141/261)