mikem@ibmpa.awdpa.ibm.com (06/15/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. Is >this true, and if so WHY? PM is the interface that is the one true interface you should code to :-) (same reason all cars have round steering wheels, etc.) >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. No, you can still use the 16 bit AVIO. Maybe if the market still wants AVIO, then development effort for 32bit AVIO will happen, just don't think it was all that important in what the beta code needed. > >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? I believe this is called thunking. (*** Sources of programming info on OS/2 V2.0 ***) See MSJ V5N3 (May 1990) for a full list of OS/2 V2.0 apis and their 16/32 bit attributes. Also see the IBM Personal Systems Developer mag (and the Best of the IBM Personal Systems Developer, MS Press) for more info on 32 bit apis/programming. Also, Starting with the August 1990 issue of PC Magazine, both Ray Duncan and Charles Petzold cover V2.0 apis such as memory mgt, semaphores, PM bitmaps and GPI up to (about) January 25th when they got moved over to Windows 3.0 (and have been complaining about ever since ;). >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...) YES! > >Does this also mean that LPEX will be consigned to 16 bits forever ? >(sob, sob...) > I doubt it pretty much. LPEX will continue to be enhanced as most products are these days. 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
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (06/15/91)
In article <1991Jun14.221153.10481@ibmpa.awdpa.ibm.com> mikem@ibmpa.awdpa.ibm.com writes: >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. Is >>this true, and if so WHY? > >PM is the interface that is the one true interface you should code to :-) >(same reason all cars have round steering wheels, etc.) > But can you write a program in plain ordinary legal ANSI C (including all of the io routines) and have it run in a window? If not, this is a very bad thing. Or, alternatively, is there a regular command interpreter that will run in a window, as command.com will in MS Windows. (This latter implies, of course, a full 32 bit program.) I like having windows, but really want command windows. Doug McDonald
peterf@stovm1.vnet.ibm.com (Peter Forsberg) (06/17/91)
mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: > But can you write a program in plain ordinary legal ANSI C (including all > of the io routines) and have it run in a window? If not, this is a very >bad thing. Or, alternatively, is there a regular command interpreter that will > run in a window, as command.com will in MS Windows. (This latter implies, > of course, a full 32 bit program.) > > I like having windows, but really want command windows. > > Doug McDonald Yes you can write plain ANSI C programs (using printf et al for i/o), they WILL be all 32-bit, and they WILL run in a window. You don't need any other command processor than CMD.EXE to run such programs. Hope that this clarifies things... / Peter -- Peter A. Forsberg Royal Institute of Technology, Stockholm, Sweden. IBM Sweden, Banking & Finance Applications. E-mail: peterf@stovm1.vnet.ibm.com (or d88-pfo@nada.kth.se) $include <standard.disclaimer>