roper@june.cs.washington.edu (Michael Roper) (07/20/89)
Someone mentioned to me that they couldn't build debugging Windows because the setup program bombs in the middle of installation. I have seen this problem before and solved it by copying all the necessary floppies to my hard disk (one subdir per) and installing from there. I don't know what the real problem is but this approach has never failed me. The "Cannot write device AUX" message box that comes up under debugging Windows indicates that Windows is executing a function called FatalExit(), which tries to dump a stack trace to the com port. The message appears because you don't have a terminal connected to the port to receive the trace. My preferred approach is to just use a regular monochrome monitor and a special device driver called ox.sys, which traps AUX output and displays it on the monitor. The driver is available either with the SDK or from Online, I believe. FatalExit() returns a code, indicating the reason for the abnormal termination. These codes (RIPs) are documented in the SDK and in some other Windows programming books. The function itself is documented in the SDK. If you run debugging Windows under Symdeb or Codeview and RIP, you can just break out and start tracing through code. Michael Roper hDC Computer Corp.
roper@june.cs.washington.edu (Michael Roper) (07/23/89)
Mark Hanner writes: > There is a reason that there are not very many windows > applications: it's very hard to make them work ... on > every bizarre configuration of PC in the world. Could you elaborate on this? What problems have you had in this regard? Of course, machine-independence is one of Microsoft's biggest selling points in promoting the development of applications for the Windows environment. So I'd be interested to hear about yours or anyone else's experiences to the contrary. Michael Roper hDC Computer Corp.
markh@rtech.rtech.com (Mark Hanner) (07/25/89)
In article <8776@june.cs.washington.edu> roper@june.cs.washington.edu (Michael Roper) writes: >> There is a reason that there are not very many windows >> applications: it's very hard to make them work ... on >> every bizarre configuration of PC in the world. > >Could you elaborate on this? What problems have you had >in this regard? Of course, machine-independence is one >of Microsoft's biggest selling points in promoting the >development of applications for the Windows environment. >So I'd be interested to hear about yours or anyone else's >experiences to the contrary. Yes, windows allows you to write applications that run on a wide range of displays and pc configurations, but the problem is that it is up to the programmer to do it right. Windows forces you to write the code that sets up the mappings for the video system, and unless you do it right, your program will probably only work for a small set of video cards. I've also run into subtle problems running on expanded memory set ups (which i could not fix because i have but one development system without the features that cause the problem; if you want to test your apps sufficiently i don't see how you can do it without having alot of hardware....). I think my main point is that there is a great leap from programming in a single-threaded terminal environment to any "object-oriented" window manager, and the development support tools simply aren't there (symdeb is barely usable for dos applications, but is ludicrous for windows. i want a combination of spy (with decodings of the messages) and codeview...). until the tools are there, building windows application will continue to be part alchemy. cheers, mark hanner -- markh@rtech.COM "Crass generalizations may be justified by admitting 10 exceptions." -- marnie applegate
roper@june.cs.washington.edu (Michael Roper) (07/26/89)
Mark Hanner writes: > Windows forces you to write the code that sets up the mappings > for the video system, and unless you do it right, your program > will probably only work for a small set of video cards. I'm not sure what this means. Could you give an example? > I don't see how you can [test a program] without having alot of > hardware. I think a 386 with EMS and a multi-mode VGA will cover it in most cases. Certainly, writing conventional DOS software to run on "every conceivable PC-compatible configuration" would require at least this much hardware, if not significantly more. > ...the development support tools simply aren't there (symdeb is > barely usable for dos applications, but is ludicrous for windows. > ...until the tools are there, building windows application will > continue to be part alchemy. This is a different issue, but you'll get (almost) no argument from me. Better tools are always welcome. Still, while a tool such as symdeb is hard to use, it is nevertheless quite powerful. Some very solid and complex Windows applications have been built using it. What tools would you like to have? This is an interesting subject and I wouldn't mind seeing some discussion on it. My pet peeve is the uselessness of the dialog editor. It could be made a lot smarter. I'd like to see support for handling custom controls for one thing, and a better user interface with operations such a one-touch centering. As it is, I can't use it and have to edit all my dialog templates by hand. Entertaining it's not. Michael Roper hDC Computer Corp.
ano@blake.acs.washington.edu (John Michael Ano) (07/27/89)
This posting is in response to Michael Roper's request for some discussion of development tools in a Windows environment. I am not a professional programmer, but I hope the following comments prove useful. First of all, CodeView is nice, only if you have a dual-monitor system. For people developing apps on a PS/2 system, this can be a pain (as one other poster has mentioned), as one would imagine the supply of Micro Channel display adaptors is small and the price tag large. I called the Microsoft support line and found out how to do screen switching on one monitor (/S switch in cvw), but when I tried it, any mouse movement on the CodeView screen caused the display to freeze up. I had to resort to toggling the screen switch to clean up the display, redraw the CodeView display with the @ command, and then continue with my trace.. Is it that difficult to have a debugger switch between the run-time screen and the debug screen? Spy has proved invaluable, and in many of my debugging sessions, simply using message boxes to show the contents of variables and pointers has helped. I haven't tried symdeb, but I think rather than try it, I'll wait for a better debugger to hit the market. If I could spec the next version of CodeView for Windows, I'd give it better screen switching capabilities. John Ano Dept. Psychology, University of Washington.
s33957e@saha.hut.fi (Petri Kalervo Havanto) (07/27/89)
<ano@blake.acs.washington.edu> writes: >First of all, CodeView is nice, only if you have a dual-monitor system. Now this is getting somewhat irritating! You people have been giving evaluations of this Windows-CodeWiev for some time, and down here even the importer seems to be unaware of it's existence. I do know that it is a long way across Atlantic, but still... Would someone over there please tell something about the creature, is it as good as DOS-CodeWiev, does it function alike and finally, is it worth the trouble trying to get one here directly from States? I'm working on a PS/2 so would some person from Microsoft please tell something about solutions to screen-switching problems mentioned by John? Thanks -- Petri Havanto s33957e@saha.hut.fi.UUCP
roper@june.cs.washington.edu (Michael Roper) (07/27/89)
Petri Kalervo Havanto writes: > You people have been giving evaluations of [Codeview for Windows] > and down here even the importer seems to be unaware of it's existence. Codeview for Windows (CVW.EXE) is part of the Windows SDK v2.1. It is not part of any earlier version of the SDK. Michael Roper hDC Computer Corp.
markh@rtech.rtech.com (Mark Hanner) (07/28/89)
In article <8804@june.cs.washington.edu> roper@june.cs.washington.edu (Michael Roper) writes: >Mark Hanner writes: >> Windows forces you to write the code that sets up the mappings >> for the video system, and unless you do it right, your program >> will probably only work for a small set of video cards. > >I'm not sure what this means. Could you give an example? I am referring to the mapping modes for text(fonts) and graphics (Petzold talks about these in chaps. 3, 12 and 15). Certainly once you get them set up and parameterize all your code, you have a nice virtual device interface, but its more code you have to write where bugs can develop. It is also all too easy to hack in hard codings that work fine on a 640x450 but produce unpredictable results on 800x600 and forget about them. I'd prefer to work only in logical units and have the system deal with the pixels (I think NeWS does a pretty good job of this...). I've seen my programs die horridly on machines with different memory set ups than mine, and I'm sure its my convoluted dynamic memory routines. I guess I want a real operating system that properly handles memory so i don't have to in my program... My main point is that windows gives me too many opportunities to slam my thumb with that I shouldn't have to worry about. Maybe Windows 3.0 will solve all these things... > >> I don't see how you can [test a program] without having alot of >> hardware. > >I think a 386 with EMS and a multi-mode VGA will cover it in most >cases. Certainly, writing conventional DOS software to run on >"every conceivable PC-compatible configuration" would require at >least this much hardware, if not significantly more. I don't think this is an either-or. Now you have to deal with BOTH DOS and Windows anomalies. There are also other layers of software (video drivers and the like) where you are forced to decide between telling your customers, "It's the driver's problem, go get a 'working' driver", or "okay, i'll hack around the goofy driver to make my program work on your system." I think we agree that this is not a simple problem. >> ...the development support tools simply aren't there (symdeb is >> barely usable for dos applications, but is ludicrous for windows. >> ...until the tools are there, building windows application will >> continue to be part alchemy. > >This is a different issue, but you'll get (almost) no argument from >me. Better tools are always welcome. Still, while a tool such as >symdeb is hard to use, it is nevertheless quite powerful. Some >very solid and complex Windows applications have been built using it. No doubt. Still doesn't make it easy to use, which brings us to.... >What tools would you like to have? This is an interesting subject >and I wouldn't mind seeing some discussion on it. My pet peeve is >the uselessness of the dialog editor. It could be made a lot smarter. >I'd like to see support for handling custom controls for one thing, >and a better user interface with operations such a one-touch centering. >As it is, I can't use it and have to edit all my dialog templates by >hand. Entertaining it's not. > > >Michael Roper >hDC Computer Corp. I want a higher level language to work in than C. Let the system keep track of my device contexts and ID's and so on, combined with a dialog editor to put the current one to shame. Favorite addition to the dialog editor: handle user defined classes with encapsulated methods to run them with... Spy also needs to decode message id's...I'll think of others... cheers, mark -- markh@rtech.COM "Crass generalizations may be justified by admitting 10 exceptions." -- marnie applegate
kensy@microsoft.UUCP (Ken Sykes) (07/30/89)
>I want a higher level language to work in than C. Let the system keep track >of my device contexts and ID's and so on, combined with a dialog editor >to put the current one to shame. Favorite addition to the dialog editor: >handle user defined classes with encapsulated methods to run them with... >Spy also needs to decode message id's...I'll think of others... > >cheers, >mark > Maybe you should consider Actor. It seems to handle most of the housekeeping for you. Most software magazines (i.e. Dr. Dobbs) have ads for it. Ken Sykes Microsoft These are personal opinions and do not reflect any official Microsoft position.
roper@june.cs.washington.edu (Michael Roper) (07/30/89)
[I asked for an example of why one would be forced to write code that was video device-specific.] Mark Hanner writes: > Certainly once you get [the mapping modes] set up and parameterize > all your code, you have a nice virtual device interface, but its > more code you have to write where bugs can develop. > It is also all too easy to hack in hard codings that work fine on > a 640x450 but produce unpredictable results on 800x600 and forget > about them. This again, is a different issue. The point here seems to be that writing parameterized code is harder than writing single-case code or that writing poor code is easier than writing good code. Obviously, you'll not find many that disagree. However, your original assertion was that one was -forced- to write different code for different displays. I still haven't seen an example of this. Which is not to say there aren't some, there are. But I don't believe it is a damning problem (and will be improved in 3.0). The gist I get from your remarks is that Windows is a complex platform for which it is hard to write and debug applications. No question about it, it's true. But when you say that you can't write a Windows application to run on any system that Windows runs on, without writing a lot of device- and machine-dependent code, I disagree. Note that I am not saying that the platform does not have bugs which may occasionally require a work-around. But it hardly seems reasonable, for example, to claim that Windows is not machine-independent because someone wrote a Windows driver with a bug. Michael Roper hDC Computer Corp.
markh@rtech.rtech.com (Mark Hanner) (07/31/89)
In article <8850@june.cs.washington.edu> roper@june.cs.washington.edu (Michael Roper) writes: >[I asked for an example of why one would be forced to write code >that was video device-specific.] >Mark Hanner writes: >> Certainly once you get [the mapping modes] set up and parameterize >> all your code, you have a nice virtual device interface, but its >> more code you have to write where bugs can develop. > >> It is also all too easy to hack in hard codings that work fine on >> a 640x450 but produce unpredictable results on 800x600 and forget >> about them. > >This again, is a different issue. The point here seems to be that >writing parameterized code is harder than writing single-case code >or that writing poor code is easier than writing good code. Obviously, >you'll not find many that disagree. However, your original assertion >was that one was -forced- to write different code for different >displays. I still haven't seen an example of this. Which is not >to say there aren't some, there are. But I don't believe it is a >damning problem (and will be improved in 3.0). "Please do not misundertake me, please..." what i really meant was that you are *forced* to write *parameterized code* if you're going to work in windows. You *can* get away with hacks in DOS (code to MONO or CGA spec and do nothing fancy, and the Microsoft C libraries perform magic for you); those who wish to move to windows are going to have to relearn programming the "right" way. I admit to being a "recovering hacker," and am no longer writing: #define XWINSIZE 200 ... CreateWindow(xxx,XWINSIZE,... but rather: int screensize; int xwinsize; ... screensize = GetSystemMetrics(SM_CXSCREEN); xwinsize = screensize/2; CreateWindow(...,xwinsize,...) /* then more mumbo jumbo below to set up map modes and text * metrics to make sure that things fit into whatever xwinsize * happens to be... */ Power comes at the expense of complexity. I would agree that its easier to write code for different devices, etc. in windows than in DOS, but you do have to make an investment in it to get the return. I'm now building a library to hide away this stuff away from the rest of my code, but I had to write it myself. Like I mentioned in my previous posting, I'd really like a higher level interface. [On the suggestion of Actor from Ken at Microsoft: I think Actor is heading in the right direction, but it's only the first generation...] cheers, mark -- markh@rtech.COM "Crass generalizations may be justified by admitting 10 exceptions." -- marnie applegate