cs_b144@ux.kingston.ac.uk (Ian Stickland) (06/11/91)
From what I've heard and read about OS/2 2.0 it would appear that
the VIO, KBD, and MOU calls have only been kept as 16bit calls. Is
this true, and if so WHY?
If so, does this mean that the PM AVIO interface is also 16bit? I
hope it doesn't, as the VIO is extremely useful for terminal
emulations and editors. If this is the case does this mean that
we are supposed to use PM for all output?? Doesn't this somewhat
restrict our options.
I've also heard/read that it will be possible to have applications
that are a mixture of 16/32 bit code. Again, is this true, and how
does this work? Would this be a way (yeuk!) of using AVIO calls
under PM perhaps?
Does this ultimately mean that the use of full-screen applications
or development of such programs is being discouraged ?? (Or are
Boca trying to force Austin into making Communications Manager a
full PM application...)
Does this also mean that LPEX will be consigned to 16 bits forever ?
(sob, sob...)
Cheers,
Ian Stickland.seg@ingres.com (scott e garfinkle) (06/12/91)
In article <1991Jun11.105427.8068@kingston.ac.uk> cs_b144@ux.kingston.ac.uk (Ian Stickland) writes: > >From what I've heard and read about OS/2 2.0 it would appear that >the VIO, KBD, and MOU calls have only been kept as 16bit calls. >this true, and if so WHY? Up front caveat: I am not a PM programmer. If the API doesn't start with "Dos", I haven't used it. It really doesn't make any difference that VIO, et al., are only available as 16-bit calls. I think that, in general, only calls of a portable nature were given 32 bit interfaces. By definition, calls such as VIO are fairly PC-specific. In any case, it is pretty easy to write mixed 32/16 bit interface programs. There is a new _far16 keyword to facilitate this, and the Microsoft SDK documentation is unexpectedly lucid in this area. The only penalty is, of course, that the calls may end up with some extra address-mapping and segment-loading overhead. Since you already had the segment overhead in the 16 bit world, and the address mapping consists of about two instructions (a SHR and a MOV, as I recall), I can't get too worked up. I suspect that, in the long run, you will be better off for speed going through PM. I dunno -- I still have no great desire to do user interfaces. -scott e. garfinkle
rommel@Informatik.TU-Muenchen.DE (Kai-Uwe Rommel) (06/13/91)
I have found, that with correct programming, the ANSI sequences and DosWrite() is quite sufficient to achieve very fast screen output. You may have noticed the less-2, beav-2 and gnuinfo postings in comp.binaries.os2. All three are ported Unix programs for which I have used termcap and good buffering (1-2k) and binary mode for stdout to get them running. The result is really fast. To achieve the same with VIO, you need to write directly to the VIO screen buffer and this is *much* more non-portable. I have done this with a MicroEMACS port and it was much more work and looked ugly. So far for the VIO API. I have used only a single VIO call to determine the screen or window size. For KBD and MOU, there is no such easy substitute. But I don't need and mouse interface at all in VIO programs. To use kbd and mou simultaneously one has to use more than one thread and semaphores to get programs that don't use too much of the CPU while waiting for an event. I am not shure if this is worth the trouble. (It wasn't for me so I have removed the mouse interface from the MicroEMACS version I use). Kai Uwe Rommel /* Kai Uwe Rommel, Munich ----- rommel@lan.informatik.tu-muenchen.dbp.de */ DOS ... is still a real mode only non-reentrant interrupt handler, and always will be. -Russell Williams
larrys@watson.ibm.com (06/14/91)
In <1991Jun11.105427.8068@kingston.ac.uk>, cs_b144@ux.kingston.ac.uk (Ian Stickland) writes: > >From what I've heard and read about OS/2 2.0 it would appear that >the VIO, KBD, and MOU calls have only been kept as 16bit calls. Is >this true, and if so WHY? This is true, last time I heard. I don't know why. >If so, does this mean that the PM AVIO interface is also 16bit? I >hope it doesn't, as the VIO is extremely useful for terminal >emulations and editors. If this is the case does this mean that >we are supposed to use PM for all output?? Doesn't this somewhat >restrict our options. I don't know. >I've also heard/read that it will be possible to have applications >that are a mixture of 16/32 bit code. Again, is this true, and how >does this work? Would this be a way (yeuk!) of using AVIO calls >under PM perhaps? This will be possible, via thunks. I don't know the details. >Does this ultimately mean that the use of full-screen applications >or development of such programs is being discouraged ?? (Or are >Boca trying to force Austin into making Communications Manager a >full PM application...) Full-screen apps have always been discouraged by those who feel it is time to let progress progress. Whether or not the OS/2 folks (the Boca Bunch) feel this way, I don't know. I have been pushing to get Comm. Mgr. and LAN Req. to become PM apps, but I don't know what the current status of that is (nor could I tell you if I knew, I'm sure). >Does this also mean that LPEX will be consigned to 16 bits forever ? >(sob, sob...) LPEX? What's that? Never heard of it... ;) Cheers, Larry Salomon, Jr. (aka 'Q') LARRYS@YKTVMV.BITNET OS/2 Applications and Tools larrys@ibmman.watson.ibm.com IBM T.J. Watson Research Center larrys@eng.clemson.edu Yorktown Heights, NY Disclaimer: The statements and/or opinions stated above are strictly my own and do not reflect the views of my employer. Additionally, I have a reputation for being obnoxious, so don't take any personal attacks too seriously.
mikem@ibmpa.awdpa.ibm.com (06/18/91)
Oh, found another reference to why Vio, Kbd, and Mou are going away: Charles Petzold wrote back in August of 1990 (PC Magazine Environments Column) and sayd these functions were "tightly linked to PC Hardware" as OS/2 becomes portable, these routines would be a confusing. Better to use C runtime library or PM calls. If you need a good primer on doing text in PM, here are my references: Petzold, Charles. Programming the OS/2 Presentation Manager PC Magazine V8N17 (Oct 17, 1989) The Marriage of Text and Graphics 1 PC Magazine V8N18 (Oct 31, 1989) The Marriage of Text and Graphics 2 regards, ~ Michael R. MacFaden IBM Palo Alto Marketing Systems mikem@ibmpa.awdpa.ibm.com, macfaden@paloic1.vnet.ibm.com disclaimer: what I write above is not necessarily my employer's opinion