ziegenfE@batman.moravian.EDU (Eric Wyette Ziegenfus) (03/23/90)
Is there any way to do graphics in OS/2 without spending the time to learn the PM programmers interface? Something that would allow just drawing graphics like DOS provides. -- Eric W. Ziegenfus ziegenfE@moravian.edu --------------------- "No matter where you go, there you are!"
Will@cup.portal.com (Will E Estes) (03/25/90)
< Is there any way to do graphics in OS/2 without spending the time to < learn the PM programmers interface? Something that would allow just < drawing graphics like DOS provides. It's amazing to me that this is the first time I've seen this question asked. Somehow we have been convinced into thinking that OS/2 application means PM application where anything more than a utility or systems software program is concerned. I doubt this assumption is anything more than focused public relations on behalf of those trying to push PM as an industry-standard.
smeans@microsoft.UUCP (Scott MEANS) (03/25/90)
In article <1289@batman.moravian.EDU> ziegenfE@batman.moravian.EDU (Eric Wyette Ziegenfus) writes: >Is there any way to do graphics in OS/2 without spending the time to >learn the PM programmers interface? Something that would allow just >drawing graphics like DOS provides. It is possible to do non-PM graphics under OS/2 by using the VioSetMode() API to go to graphics mode. This will only work (correctly) in a full screen session to the best of my knowledge. I would recommend that you use the Gpi from a PM program, however. It buys you device independance and a standard interface for your program with a small initial learning curve considering the functionality that is gained. -- /\/\ //\/\\ \> </ S/ \eans
chrisl@caen.engin.umich.edu (Chris Lang) (03/25/90)
In article <28236@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: >< Is there any way to do graphics in OS/2 without spending the time to >< learn the PM programmers interface? Something that would allow just >< drawing graphics like DOS provides. > >It's amazing to me that this is the first time I've seen this question >asked. Somehow we have been convinced into thinking that OS/2 application >means PM application where anything more than a utility or systems >software program is concerned. I doubt this assumption is anything more >than focused public relations on behalf of those trying to push PM as >an industry-standard. If only your statement were true... ("...OS/2 application means PM application...") With every new release of OS/2, it becomes more and more obvious that the intention is to encourage PM rather than full-screen applications. I can't think of many reasons not to use PM, especially for graphics-oriented applications. Unwillingness to learn the API doesn't strike me as a good reason (it really isn't as tough as some people make it out to be; I learned it in a couple of weeks with only the reference manuals and Petzold's book, and if *I* can, anyone can). Now, after that brief tirade, I can say that there is no directly supported way to do graphics without using PM. That's not to say it isn't possible, since it most definitely is. But don't expect it to be as nice as using GPI for everything...wish I could help you more, but I really would suggest that doing it under PM is probably the wisest move (the time it will take you to work around OS/2 to draw directly on the screen will probably more than offset the time it would take you to learn PM and GPI, IMHO). Just a couple of thoughts... -Chris -- Chris Lang, University of Michigan, College of Engineering +1 313 763 1832 4622 Bursley, Ann Arbor, MI, 48109 chrisl@caen.engin.umich.edu WORK: National Center for Manufacturing Sciences, 900 Victors Way, Suite 226, Ann Arbor, MI, 48108 +1 313 995 0300 "I hate quotations. Tell me what you know." - Ralph Waldo Emerson
ziegenfE@batman.moravian.EDU (Eric Wyette Ziegenfus) (03/26/90)
I realize the benifits of following the PM interface, but have a hard time convincing my superiors of the time investment need to learn PM. Since we already have code developed for the DOS environment. Eric W. Ziegenfus ziegenfE@moravian.edu -- Eric W. Ziegenfus ziegenfE@moravian.edu --------------------- "No matter where you go, there you are!"
bright@Data-IO.COM (Walter Bright) (03/27/90)
In article <1289@batman.moravian.EDU> ziegenfE@batman.moravian.EDU (Eric Wyette Ziegenfus) writes:
<Is there any way to do graphics in OS/2 without spending the time to
<learn the PM programmers interface? Something that would allow just
<drawing graphics like DOS provides.
Blowing my own horn here, Zortech C and C++ for OS/2 provide graphics
support for non-PM programs. As far as I know, of OS/2 C compilers,
Zortech's is the only one that does.bmarsh@cod.NOSC.MIL (William C. Marsh) (03/27/90)
In article <1990Mar25.014347.25497@caen.engin.umich.edu> chrisl@caen.engin.umich.edu (Chris Lang) writes: >In article <28236@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: >>< Is there any way to do graphics in OS/2 without spending the time to >>< learn the PM programmers interface? >> >>It's amazing to me that this is the first time I've seen this question >>asked. Somehow we have been convinced into thinking that OS/2 application >>means PM application... > >With every new release of OS/2, it becomes more and more >obvious that the intention is to encourage PM rather than full-screen >applications. I can't think of many reasons not to use PM, especially >for graphics-oriented applications. How about speed? Ever try to write animation programs through an API which can switch tasks almost at will? Or a program that doesn't use the normal event/processing/drawing/'wait for next event' loop? One problem with every windowing/graphics system I have ever programmed for (Windows, PM, Sunview, Mac) is that if you try to do something slightly different from the windowing 'model' in use is like pulling teeth. It reminds me of the Murphy's law, "If all you have is a hammer, everything looks like a nail..." >Now, after that brief tirade, I can say that there is no directly supported >way to do graphics without using PM. That's not to say it isn't possible, There are VIO calls to put the screen into graphics mode, and also a call to return the screen segment selector. If you are programming in the EGA/VGA 16 color modes, then you will also require IOPL to be YES (since we need access to the bit mask register, etc.). But I would say there is documented support for graphics calls under OS/2 without PM! -- Bill Marsh, Naval Ocean Systems Center, San Diego, CA {arpa,mil}net: bmarsh@cod.nosc.mil uucp: {ihnp4,akgua,decvax,dcdwest,ucbvax}!sdcsvax!nosc!bmarsh "If everything seems to be coming your way, you're probably in the wrong lane."
alistair@microsoft.UUCP (Alistair BANKS) (03/27/90)
In article <1990Mar25.014347.25497@caen.engin.umich.edu> chrisl@caen.engin.umich.edu (Chris Lang) writes: >In article <28236@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: >>< Is there any way to do graphics in OS/2 without spending the time to >>< learn the PM programmers interface? Something that would allow just >>< drawing graphics like DOS provides. >> >>It's amazing to me that this is the first time I've seen this question >>asked. Somehow we have been convinced into thinking that OS/2 application >>means PM application where anything more than a utility or systems >>software program is concerned. I doubt this assumption is anything more >>than focused public relations on behalf of those trying to push PM as >>an industry-standard. > >If only your statement were true... ("...OS/2 application means PM >application...") With every new release of OS/2, it becomes more and more >obvious that the intention is to encourage PM rather than full-screen >applications. I can't think of many reasons not to use PM, especially >for graphics-oriented applications. Unwillingness to learn the API doesn't >strike me as a good reason (it really isn't as tough as some people make it >out to be; I learned it in a couple of weeks with only the reference manuals >and Petzold's book, and if *I* can, anyone can). > >Now, after that brief tirade, I can say that there is no directly supported >way to do graphics without using PM. That's not to say it isn't possible, >since it most definitely is. But don't expect it to be as nice as using >GPI for everything...wish I could help you more, but I really would suggest >that doing it under PM is probably the wisest move (the time it will take you >to work around OS/2 to draw directly on the screen will probably more than >offset the time it would take you to learn PM and GPI, IMHO). > Well, I know this is likely to cause some to rant and rave, but I'll try to straighten some things out - and give reasons for some direction in OS/2. #1. Graphics programs can be written under os/2 using much the same techniques as you used under dos - ie, you change screen mode, then you toggle i/o ports and you toggle bits on screen and you've done the work. Your work is specific to cga/ega/vga or whatever subset of adaptor you uderstand. #2. PM is a better way. The direction for OS/2 is that, since PM is, and will remain, an in-built part of os/2 - we believe the majority of successful os/2 programs will have their user interface written for PM. This is true today, and will become truer over time. Therefore we make PM easier, and we will make it easier still. You are unlikely to find non-PM applications becoming easier to write. What will make graphics programming easier will be the availability of tools and libraries which themselves handle PM and leave something more familiar or 'easier' (although this depends on your point of view). We are right to try to get ISVs standardize on a graphics API and PM with GPI are the standards we are setting. GPI is a drawing library which is consistant and available for all OS/2 supported screens and printers. This list will increase over time. (I will not enter into which screen/which printer discussions). The greatest advatage is that we are putting resposibility for supporting standard APIs in the hands of oems, so that ISVs can write to the smallest number of standard APIs and oems will be motivted to do the support work for their hardware. This will allow much greater improvement in hardware than today where we are constantly restricted by the demand of backwards compatibility. Enough said. I urge you to use Presentation Manager when writing the user interface portion of you OS/2 application - I similarly urge you to use GPI as PM's graphics library when writing to your printer. This is not marketing BS. Alistair Banks OS/2 Group Microsoft
chrisl@caen.engin.umich.edu (Chris Lang) (03/27/90)
In article <1838@cod.NOSC.MIL> bmarsh@cod.nosc.mil.UUCP (William C. Marsh) writes: >In article <1990Mar25.014347.25497@caen.engin.umich.edu> chrisl@caen.engin.umich.edu (Chris Lang) writes: >>In article <28236@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: >>>< Is there any way to do graphics in OS/2 without spending the time to >>>< learn the PM programmers interface? >>> >>>It's amazing to me that this is the first time I've seen this question >>>asked. Somehow we have been convinced into thinking that OS/2 application >>>means PM application... >> >>With every new release of OS/2, it becomes more and more >>obvious that the intention is to encourage PM rather than full-screen >>applications. I can't think of many reasons not to use PM, especially >>for graphics-oriented applications. > >How about speed? Ever try to write animation programs through an API which >can switch tasks almost at will? Or a program that doesn't use the normal >event/processing/drawing/'wait for next event' loop? It's entirely possible to write compliant animation programs in a pre-emptive multitasking environment; whether or not its possible under PM or not is another story, but don't assume just because it can't be done on IBMs it can't be done. >One problem with every windowing/graphics system I have ever programmed for >(Windows, PM, Sunview, Mac) is that if you try to do something slightly >different from the windowing 'model' in use is like pulling teeth. It reminds >me of the Murphy's law, "If all you have is a hammer, everything looks like >a nail..." Very true. But I don't see it as being as bad under PM as under, say, the Mac. (I am fairly ignorant of programming the Mac, but I have been given the impression that there is a right way to do things, Apple's, and a wrong way, and never the twain shall meet.) > >There are VIO calls to put the screen into graphics mode, and also a call >to return the screen segment selector. If you are programming in the EGA/VGA >16 color modes, then you will also require IOPL to be YES (since we need >access to the bit mask register, etc.). But I would say there is documented >support for graphics calls under OS/2 without PM! I confess...I didn't type at all what I wanted to say. I know you can do full-screen graphics under OS/2; what I MEANT to say is that there's no equivalent of the GPI for non-PM applications. I apologize for the confusion that caused. (Trying desperately to head off a dozen postings and twice as many letters telling me I'm wrong...I know I know I know! :-) >Bill Marsh, Naval Ocean Systems Center, San Diego, CA >{arpa,mil}net: bmarsh@cod.nosc.mil >uucp: {ihnp4,akgua,decvax,dcdwest,ucbvax}!sdcsvax!nosc!bmarsh >"If everything seems to be coming your way, you're probably in the wrong lane." -Chris -- Chris Lang, University of Michigan, College of Engineering +1 313 763 1832 4622 Bursley, Ann Arbor, MI, 48109 chrisl@caen.engin.umich.edu WORK: National Center for Manufacturing Sciences, 900 Victors Way, Suite 226, Ann Arbor, MI, 48108 +1 313 995 0300 "I hate quotations. Tell me what you know." - Ralph Waldo Emerson
jim@tct.uucp (Jim Kunzman) (03/27/90)
According to bmarsh@cod.nosc.mil.UUCP (William C. Marsh): >There are VIO calls to put the screen into graphics mode, and also a call >to return the screen segment selector. If you are programming in the EGA/VGA >16 color modes, then you will also require IOPL to be YES (since we need >access to the bit mask register, etc.). But I would say there is documented >support for graphics calls under OS/2 without PM! True you can use VIO calls in OS/2 versions before 2.0. However, Version 2.0 (386 machines) has eliminated those calls. Perhaps they will add an OS/2 1.2 compatibility box when it's released! -- Jim Kunzman at ComDev/TCT <jim@tct.uucp>, <uunet!ateng!tct!jim> "!(This space intentionally left blank.)"
jerry@walt.cc.utexas.edu (Jerry Porter) (03/28/90)
First I need to make a few assumptions:
The GPI/PM/API interface is fast enough for my graphics needs, on my current
system. Second it can fully exploite my hardware.
With these two things in mind, WHY can't PM or GPI calls do Full screen
graphics in another screen group? I have VGA right now, but my 256 colors do
me no good. I can only use them in the 320X200 mode, and I can't access this
without buying Zortech C++ OS/2 Edition with flash graphics package(no this is
not a plug, I haven't used it). These calls are all supported it would seem
trival to support mutliple screen groups. I think it might have something to
do with the way PM so tied to the operating system at such a base level.
On a totally unrelated topic: Anyone know how the 2/387 co-processor works
in a mutli-tasking operating system?
Jerry Porter AKA Bass Wastelan | Disclaimer, we don't need no stinkn'
Star's End 512-255-1030 2400baud | disclaimers.
jerry@ccwf.cc.edu.utexas |
--------------------------------------| |---------------------------|
I LIKE it. | | All roads lead to Trantor.|kushner@ux3.lbl.gov (Gary Kushner) (04/08/90)
I don't know that much aboud VCPI, but from what I've read, it isn't very good technically. There is no intertask protection. If one task crashes, it can bring the whole system down. This seems to be to be unacceptable to either OS/2 or windows 3.0. -Gary
gordonl@microsoft.UUCP (Gordon LETWIN) (04/10/90)
In article <28655@cup.portal.com>, Will@cup.portal.com (Will E Estes) writes: > Everything I have read about OS/2 2.0 makes it sound very exciting. However, > Microsoft's decision to not support VCPI means that millions of Lotus users, > 386-to-the-Max users, and users of products based on DOS/16M and other DOS- > extender products will not be inclined to upgrade to OS/2. The problem is that under VCPI, the various applications run in "ring 0 protected mode". This means that there is no memory management protection and no security against such an application. For those with UNIX experience, this is the equivalent of running any application that asks for it in supervisor mode. Just think how easy this will make it for any application to fiddle the system any way that it wants. And how easy to write a virus that reads or changes any file anywhere - he just asks to run in ring 0 and then helps himself. There was recently a discussion of virus and worm protection and file system security. OS/2 could NEVER have protection if we supported VCPI. This means that it will never be successful in a corporate environment because no company is going to trust their critical operational data to a totally insecure operating system, one where anybody can read or write any data at any time. Further, if OS/2 supported VCPI we'd soon be in the DOS "ram cram" situation where all these various products fight with each other because they're doing funny things to the operating environment. Any any errors in any of these applications will cause your machine to crash, if you're lucky, or just to become flakey otherwise. How can OS/2 be successful if a user who has a half dozen favorite VCPI applications finds that he gets his files corrupted every week or so? Even if he doesn't blame OS/2, it would take a genius to figure out which app was doing the damage, if it's an intermittant problem. gordon letwin microsoft
alistair@microsoft.UUCP (Alistair BANKS) (04/11/90)
Further to this, Microsoft, Intel and many other industry leaders, including the well-known DOS extender companies got together recently to resolve the problems in current DOS-extender technologies. Micrsoft has backed the resulting proposed DPMI standard, (Dos Protect Mode Interface) and has stated that DPMI applications will be supported under a future version of Windows and a future version of OS/2. As Gordon Letwin stated, VCPI is technically inedaquate to satisfy our customer's stated requirements. DPMI enables the same important features as VCPI, and will be supported in Microsoft's operating systems. Alistair Banks OS/2 Group Microsoft
tmh@uncecs.edu (Toni M. Hutto) (04/14/90)
In article <5351@helios.ee.lbl.gov> kushner@ux3.lbl.gov (Gary Kushner) writes: > >I don't know that much aboud VCPI, but from what I've read, >it isn't very good technically. There is no intertask protection. >If one task crashes, it can bring the whole system down. >This seems to be to be unacceptable to either OS/2 or windows 3.0. > >-Gary Why did Lotus go the way of VCPI? And WHY _can't_ Windows or OS/2 support it. I suppose I don't mind waiting around for Lotus 123/G, but I need to also run version 3.0... Having 6 or 7 config.sys files right now is driving me bonkers. . . not to mention my computer from being rebooted as I go from program to program. I'm about ready to abandon windows for DESQview--if, IF it ever shows up and IF it works with apps. -- =================================================== tmh@uncecs ......................................................................... Toni M. Hutto, Wake Technical Community College, Raleigh, NC
tmh@uncecs.edu (Toni M. Hutto) (04/14/90)
In article <54030@microsoft.UUCP> alistair@microsoft.UUCP (Alistair BANKS) writes: >Further to this, Microsoft, Intel and many other industry leaders, >including the well-known DOS extender companies got together recently to >resolve the problems in current DOS-extender technologies. > >Micrsoft has backed the resulting proposed DPMI standard, (Dos >Protect Mode Interface) and has stated that DPMI applications >will be supported under a future version of Windows and a future >version of OS/2. > >As Gordon Letwin stated, VCPI is technically inedaquate to satisfy >our customer's stated requirements. DPMI enables the same important >features as VCPI, and will be supported in Microsoft's operating systems. > >Alistair Banks >OS/2 Group >Microsoft Hurray! and hurry! However, any suggestions for now about how I can handle Lotus 1-2-3 verson 3.0 without having yet another memory manager and yet another config.sys file---while I wait for apps that run in OS/2, I still need to run DOS to work with theses apps. My clients and students don't always have OS/2 or the latest OS in their boxes. Don't misunderstand me, I like MS products. In fact one of my favorite things to consult with and teach about is Excel. However, I'm running out of Advil with the Lotus issue...and it is forcing me to go the route of DESQview. ..unless you have any other suggestions! ANYone! -toni (tmh@uncecs.ed) -- =================================================== tmh@uncecs ......................................................................... Toni M. Hutto, Wake Technical Community College, Raleigh, NC