From: strobl@gmd.de (Wolfgang Strobl)
Subject: Re: Macintosh bigots
Organization: GMD, Sankt Augustin, Germany
Date: Thu, 19 Nov 1992 17:36:37 GMT

In <mmy1knq@rpi.edu> johnsd2@jec316.its.rpi.edu.its1 (Daniel Norman Johnson) writes:

[I wrote]
>>They don't. Some of them use Windows, others run OS/2, and 
>>still others use plain old DOS.

>An interesting arrangement. Would it hurt to for all video to be
>faster?

Sure. One of them has a LCD display, for which there is
more to do than just have a four byte memory interface,
in order to make it fast. Really fast LCD displays did 
cost a fortune, some years ago.

If cost doesn't matter: then no, it doesn't hurt if all 
video is faster.

>>>>>(why do I say its not fast enough? Because the PCheads
>>>>>here seem to feel that way- otherwise they'd have blown away my comment
>>>>>about Windows having a slow  GDI by demonstrating that it doens't;
>>>>>instead they say you can use an accelerated graphics board...)
>>>>
>>>>Then let's start to compare lines/second. Your turn. :-)
>>
>>>:) I dont know how many lines per second, nor does it matter terribly.
>>>(what these things do a lot of its blitting, actually..) I worry more
>>>about how snappy it feels.
>>
>>Ok. Then tell me how snappy it feels, and I will tell you how snappy
>>my system feels. After that, we compare, ok? Your turn.

>It is worth 272 FluugleZarbs. (my Patent Pending unit for Snappyness)

Octal base, of course? This is odd! Perhaps you should
drop the parity bit, before you use that number. :-)

>(its a very subjective thing ya know. How I am supposed to
>describe it? Things just sorta happen. Blits are just there. That sort
>of thing.)

Get the feeling?

Well, I'll stick with my tea, thank you.

[...]

>>>>>Does
>>>>>PM? 
>>>>
>>>>Yes, and it's a bit better, because it got the segmented
>>>>graphics architecture from IBMs GDDM instead of the flat
>>>>metafile of GDI.
>>
>>>Segments? Yech! :)
>>
>>Big grin. :-}
>>
>>>Actually, I dont see what you mean by this.. segmented?
>>
>>You can put a list of primitives into graphic segments,
>>and construct complex pictures from segments and primitives.
>>A GDDM (and GPI) metafile is a tree of segments, instead
>>of a flat list of primitives.

>Oh, you mean that these metafiles can contain other metafiles?

In IBMs GDDM and OS/2 PM, yes. In the current Windows metafile,
no. But the new, enhanced Win32 API used by Windows/NT and
the WIN32S libraries for Windows 3.1 has an enhanced metafile
api, which supports embedding metafiles in other metafiles.

>PICT can do that- you can call DrawPicuter inside a picture definition.

[...]

>>>My comment about "windows support" was beacuse of this:
>>>"Even under Windows 2.0 the speaker can do much more than just beep."
>>
>>>What support is there under 2.0 beyond beeping?
>>
>>From the 3.0 SDK help file (because I have it online,
>>the 2.0 interface is identical).

>Hangon- Id be rather surprised that 3.0 added nothing at all
>to the SDK. Perhaps this is one of the things it adds.

Arrgh. The list of API functions I quoted was quoted from
the 3.0 SDK help file (because I have it online, and be-
cause I am to lazy to copy the very same list from the
printed 2.0 SDK documentation). All the functions I
quoted exist in both 2.0 and 3.0 with exactly the same
semantics. This statement applies to these functions
only.  

[...]

>[deletia- accel. video AGAIN, and protection]

>>>[deletia- protection]
>>>>>>Well, any UAE is a proof that Windows has at least a little bit
>>>>>>of memory protection. That most people don't get that right,
>>>>>>and blame the messenger doesn't change that in any way.
>>>>
>>>>>And this is the thing; as you say Windows was designed in such a way
>>>>>to be sturdier that the Mac this way. So why is it (Generally)
>>>>>percieved as being crash-happy?
>>>>
>>>>I don't perceive it that way.
>>
>>>Ok. Nifty. So you dont know why people persist in saying
>>>it is? (or is it just the Great Machead Conspiracy?) :)
>>
>>I have seen MFT crash, MVS crash, BS2000 crash, CP/M crash, 
>>TSO crash, Unix crash (various flavors, of course), I
>>know how it feels if DOS, Windows, OS/2 or the Mac OS crash.
>>I even know how to crash most of them, and how to avoid
>>it, and that this is simple on some systems, and difficult
>>on others. I don't think that it is more easy to crash
>>Windows than the Mac OS, or that it is more difficult
>>to avoid.

>Ah, so it IS the Great Machead Conspiracy? Now that we have been
>found out, we'll have to go to some other front. :(

I don't see how you are able to conclude that from my above statement.

>>[...]
>>
>>>[deletia- the error of my ways. Ive already seen it.]
>>
>>>>>I dont quite see how this works. Where do the resources
>>>>>go? ARe they appended to the end or something?
>>>>
>>>>Exactly. If I remember correctly, the resource part
>>>>comes first, but I could be wrong. I don't care, because
>>>>it's the tools business to know that. 
>>
>>>Hmm.. how can you execute it then?
>>
>>Execute what? A program is excuted by using one of
>>the API calls to load and run a program. A library
>>is accessed using the LoadLibrary API call.

>Oh, so its not a DOS .exe; if you ran it in DOS it would
>crash with an illegal instruction or somesuch.

No, you can't run Windows executables in DOS, it's a
completely different format. In fact, a Windows program
usually is a concatenation of a small DOS program
which says "This is a Windows program" and the real
Windows program. The Windows executable format is
defined to allow for that.

>>>Resources wont run..
>>
>>[...]
>>
>>>[deletia- resouce modification]
>>>>>>Hm. Perhaps it wasn't such a bad idea that the Windows API doesn't
>>>>>>contain calls to modify resources ...
>>>>
>>>>>Hmm? Me no get it.
>>>>
>>>>Selfmodifying programs isn't a good idea, generally.
>>
>>>Do you mean "always" or "usually"? Ill buy the second but not he
>>>first.
>>
>>Always. A program can generate another program and run it 
>>after creation. But as an general option provided by a high level
>>interface, it is a bad concept.

>Ah. Always is a big thing. Why? (note that this is more than just
>modifiying your own code)

Selfmodifying code should be made an exception, not the rule.
Always. :-)

Wolfgang Strobl
#include <std.disclaimer.hpp>
Newsgroups: comp.os.ms-windows.advocacy,comp.sys.mac.advocacy