From: strobl@gmd.de (Wolfgang Strobl)
Subject: Re: Macintosh bigots
Organization: GMD, Sankt Augustin, Germany
Date: Sun, 15 Nov 1992 19:23:50 GMT

In <00t1hlb@rpi.edu> johnsd2@jec314.its.rpi.edu.its1 (Daniel Norman Johnson) writes:

>In article 721793765@gmd.de, strobl@gmd.de (Wolfgang Strobl) writes:
>>In <7gt1n=@rpi.edu> johnsd2@vccnw04.its.rpi.edu.its1 (Daniel Norman Johnson) writes:
>>>In article Kou@news.cso.uiuc.edu, rvenkate@ux4.cso.uiuc.edu (Ravikuma Venkateswar) writes:
>>>>johnsd2@jec328.its.rpi.edu.its1 (Daniel Norman Johnson) writes:
>>>>
>>
>>[...]
>>
>>>>>>
>>>>>>Graphics engine? Slow? Certainly not if you have an accelerated graphics
>>>>>>card!
>>>>
>>>>>Heh heh. That's true- but that just takes the GDI mostly out of the loop.
>>>>>What if you dont have/want one?
>>>>
>>>>You just have to buy one and plug it in! It's still less expensive than
>>>>a Mac!
>>
>>>Perhaps, Ive heard arguments on both sides and haven't made up my
>>>mind (yet); but you still have to spend money on it. It would be better
>>>if you did not need to do so.
>>
>>You mean, one should get the hardware for free, and only pay the
>>software?

>:) but of course! :)

Ah, you remember my joke about the oversized dongle? :-)

>Actually, I mean you should not need to have an accelerated graphics
>board.

You mean, I should not have the option to get a slower, but
inexpensive graphics interface, even if I don't need the
speed?

>>>(ps what about offscreen graphics)
>>
>>>>>(also, dont forget the bit depth you are running in. As I recall, windows
>>>>>usually uses 4 bit depth. It still seems slow to me, compared to an 8 bit
>>>>>deep Mac. Wonder what windows is like at 8 bits deep)
>>>>
>>>>_I_ run Windows at 15 bit depth. And Windows works internally at 24.
>>
>>>You use a accelerated graphics card, no? Windows does indeed use 24 bit
>>>colors internally, but I believe its offscreen bitsmaps run at the screens
>>>depth, the icons are 4 bits deep, no? Its not ALL 24 bit (or it
>>>would be even slower!)
>>
>>Well, a Device-Independent Bitmap can have 1, 4, 8 or 24 bits per
>>pixel, and doesn't depend on the screen depth. Icons are indeed 4 bits
>>deep, or less, currently. The API spec doesn't preclude more bits, how-
>>ever.  

>So indeed it isn't all done at 24 bits. (I didn't really think
>Windows was that insane. Honest.)

No, it isn't all done at 24 bits. But if you draw something and
have to use a color, you have to specify it in 3*8 bit.

>>What's wrong with accelerated graphics cards? If you need 
>>it, you can buy a PC with a preinstalled accelerator card.

>Yeah, but Windows is what is making you need one. Wouldn't it be
>nicer if you didn't?

I don't understand. Windows doesn't make me need one. In fact,
currently I don't use one. I'm using a 800x600x8 mode on a 16"
screen just now, and am satisfied with its performance. If it
will start to bother me some time in the future, I'll buy a
cheap accelerated card in the shop around the corner.

>>Btw, there are non-accelerated cards which have Windows drivers
>>for 15 or 16 bit depth. I'm using one of these, because it is
>>fast when used with 4 or 8 bit depth, acceptable with 15 bit,
>>runs with 72 Hz in all modes, and was cheap. 

>Im not talking about screen refresh, Im talking about drawing speed.

I know. But screen refresh is more important to me than raw drawing
speed. I replaced my former VGA card with the current one because 
it is able to go up to 1024x768 resolution using a >70 Hz refresh.
That it is more than three times as fast than the older card -
because of a better memory interface and because of better drivers -
was just another and secondary incentive to buy that card.

>Im glad you found a fast video card wo/ acceleration; Ive never
>seen a windows system do that, but that doesn't mean it can't
>be done.

>>>>>> And if I remember correctly, a PICT is pretty much the same as a DIB
>>>>>>in Windows.
>>>>
>>>>>What exactly is DIB? I thought it was Device Independant Bitmap, which
>>>>>isn't very much like PICT (although PICT can duplicate the functionality
>>>>>using a CopyBits operator)
>>>>
>>>>Then what _is_ a PICT? A DIB is how graphics images are stored internally
>>>>in Windows - and it's converted before display. So it can handle any
>>>>pixel pitch and color depth<24 bits.
>>
>>>PICT is basic encapsulated quickdraw commands. This means of course
>>>that its device independant; it can encode bitmaps of any depths,
>>>and they can be compressed in various ways (including JPEG compression)
>>>by using the copybits operator.
>>
>>That's quite similar to a Windows metafile. Two excerpts from the
>>online Windows 3.0 SDK helpfile:
>>
>[deletia- Metafile description]

>Nifty! I guess you guys do have something PICT. Do this have
>to be files? Can you put one in the clipboard, or make one
>a resource?

No. Sure. A metafile can be created in memory, or written to a file
without going through memory. It can be put on the clipboard (that's
the standard CF_METAFILEPICT format), or put into a resource. 
Unfortunately, the current resource compiler - and Microsofts
dialog editor - don't define a standard "metafile" resource type, so
you have to include it as a user defined resource type. 

>>
>>>But it can also use other operartions, so unlike bitmaps it can
>>>scale well to other depths; if you have stuff made by a drawing
>>>program and put it in PICT it will do this. Its also possible to take
>>>it apart again into objects.
>>
>>The same applies to metafiles.
>>
>>>Its very flexible, basically.
>>
>>Ditto.

>Heck, its essentially the same thing.

Well, it isn't such a big idea to collect a stream of calls to
some graphics interface into some container, in order to be able
to handle (i.e. store, replay, modify, ..) it. Most of the 
graphics systems I know have a similar concept.

>>>>>> And Windows also supports a wide variety of hardware for sounds -
>>>>>>like a SoundBlaster Pro - which is as good as a Mac's
>>>>
>>>>>If not better, but you can't count on a SoundBlaster being present in
>>>>>general. This isnt' really Windows fault, of course.
>>>>
>>>>But the point is that you can get one if you _need_ one.
>>
>>>Yes, you can. But why you should need one for event the simplest,
>>>tinniest sounds I dont see.
>>
>>You don't, if you only need simple sounds. There is always the 
>>speaker.

>Which can only beep under Windows, no? Or did windows pick up a driver
>for the internal speaker that I dont know about?

Even under Windows 2.0 the speaker could do much more than just
beep. 

For Windows 3.1 there is a tiny driver for the speaker, which can
be used instead of those driving the real sound cards. It isn't
included in the standard distribution, because - according to
Microsoft - it fails on a small percentage of the clones, and
MS doesn't want to support it. But it is available almost every-
where. I have it installed on all my machines, and it works
quite well. For playing music or speech it's only a toy. But
for short, characteristic sounds, it's more than enough.

>>[...]
>>
>>
>>>[deletia- Windows/PC speed]
>>>>>Quite so; I am certain you could (with sufficient effort) get the speed
>>>>>in a Windows box. But who wants to spend the effort? Once again,
>>>>>this is not all Windows' fault- I understand that the data path to your
>>>>>video cards is usually either 8 or 16 bits, not 32.
>>
>>Usually, but not for local bus video, for example.

>Ok; how common is this?

Hard to answer for me, because I bought my machine before they
became "common". But the magazines I'm reading offer various
motherbords (and complete machines) with that feature.

>>Do all Macintoshs have 32 bit access to the video memory?

>Yes; All that I know of anyway. Im not entirely sure about the Classic,
>Plus or whatnot but having b&w display only would compensate.

This implies that all macintoshs have a 32 bit external bus?

>[deletia- finding a PC]
>>>>>[deletia- Windows slow, kludgy, error prone]
>>>>>>
>>>>>>Again, if you have an accelerated card, it doesn't even draw slow. In fact,
>>>>>>now that I think about it, most computers come with Windows accelerated
>>>>>>graphics adapters (IBM's XGA-2, Compaq's QVision,... the list goes on).
>>>>
>>>>>Its news to me. Does this include cheap clones?
>>
>>Of course not! These include cheap accelerated cards, of course! :-]

>Ah, you get the card separately them?

Pardon? It was my intention to draw attention to the fact that
"accelerated" doesn't necessarily imply "expensive", in the
PC world. There are expensive accelerator cards, and there are
cheap accelerator cards.


>>>>
>>
>>[...]
>>
>>>> And
>>>>_all_ come with accelerated graphics adapters. Even some cheap clones
>>>>have had accelerated graphics adapters for about three months.
>>
>>>I didn't know this.
>>
>>They're starting to sell S3 cards for 450 DM (about 290$) here in 
>>Germany. When bundled with a machine, you'll probably get it for
>>less.

>How deep is this cards display? How many pixels does it produce?

Well, from looking at the ad, it has 1 MByte and does 1024x768x8.

I just saw another ad, where a similar card is offered for DM 380,
which is even less.

>>>>>>And Windows is not more kludgy than the Mac, and crash-prone? Not unless
>>>>>>you're using non-commercial software and/or multitasking heavily.
>>>>
>>>>>Multitasking is no excuse for an OS that was DESIGNED to do it
>>>>>(Windows); certainly NOT when you are comparing it with an OS that
>>>>>was NOT so designed (MacOS)
>>
>>That's true. But Windows follows the same principle of not 
>>trading speed for security as the MacOs does, and doesn't fully use
>>the memory protection features of the hardware segmenting because
>>of that. Because of that, an ill-behaving application can
>>crash the OS and the other running programs easily.

>That is true but has little to do with multitasking- it could just crash
>the OS if it was alone.

>The Mac was designed so that protecting it is really hard- there is
>no segmenting mechanism, you'd need to use the PMMU. You can't protect
>teh system because apps are allowed to access it (allocate memory
>and use it) and sometimes need access to OS data structures (to which
>handles are returned by routines like GetDeviceList, GetWMgrPort etc)
>and so forth. I understand Windows does catch it if an app uses an INVALID
>segment selector; shouldn't Windows be tougher because of this?

It not only catches invalid selectors, it catches invalid accesses
(write if only read is allowed, access beyond the limit), too.
It fails to use a separate local descriptor table for each task.
OS/2 1.x does that, Windows 3.x doesn't.

Windows doesn't need a program to access OS data structures, there
are no global variables, and everything is handled through the
API. So - at least in principle - Windows should allow for better
memory protection. The problem, as I see it, is that ownership
of a memory block wasn't enforced from the beginning (during real
mode time, there was no way to do so), and a later change whould
have had broken to many programs.

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.

>[mind you, Im not asserting that it is not tougher; but some people are
>and its not being disputed. That does strike me as odd]

Well, I've disputed it a few times, and I'm a bit puzzled, too.

>[deletia- Is it live or is it Shareware?]

>>>>>As for the kludgy thing, sure looks kludgy to me. You still have to
>>>>>have separate files for your (non-editable) resources, right? Kludge!
>>>>
>>>>Resources are editable with programmers' tools. Users don't have to edit
>>>>resources. And they're easier to use for multiple executables if they are
>>>>in separate files (any executable can share a DLL).
>>
>>>But you MUST put them in separate files- ALWAYS. This means that
>>>a program CANNOT be one file. That sux.
>>
>>This is not true, plain and simple.
>>
>>Because I don't understand what you refer to, would you care
>>to explain your statement?

>Hey, now waitasec. If you dont understand what I am saying,
>how come you are assertting that it is not true?

Well, I implied that I don't expect you to make such an obviously
false statement, so I supposed a misunderstanding on my side and
asked you to carify your statement. I'm sorry if I didn't make
that clear.

>I am saying that:
>	- Windows programs must have SEPARATE resource files-
>	  you cant put the resources in the .EXE.

No. It's exactly the opposite. Resources have to reside in 
.exe files (the suffix doesn't matter - it has to be a 
"new executable" format load module, .drv, .dll, exe, .fnt
and so on are all of that type), in order to be accessible
to running programs, using the standard resource access
methods.

The resource compiler is responsible both for compiling
a textual description of a resource into a binary format,
and for attaching this binary to a raw (i.e. resource-less
and non-executable .exe file). 

Well, now that I'm starting to explain this: why don't
you get a copy of the bible of Windows programming,
Petzolds "Programming Windows"? He can explain this
much better than I do.

>	- You will virtually always need (or at least want) to use
>	  resources in windows programs.

Agreed.

>	- Doing so requires some sort of resource file.
>	- Hence, Windows program require a separate resource file,
>	- Hence Windows programs can't live in one file only.

>Which part is wrong?

The conclusion from "you need resources" to "they have to
reside in separate resource files" is wrong.

The average Windows program consists of a resources and one
piece of code. The resources usually consist of
 an icon,
 a menu,
 an accelerator table, and
 various dialog templates,
which reside in various files during the development stage.
Usually, one has one master resource-definition file, i.e.
a script that describes all the resources used by the 
applications. This is compiled into a binary resource
file (usuall suffix: .res) using the resource compiler.
The compiler reads all the files (icons, bitmaps, other
binary resources) include by the script, compiles the
menu and dialog template descriptes and produces one single
output file. THIS FILE CAN'T BE USED BY WINDOWS.

Instead, you have to call the resource compiler a second
time in order to attach that compiled resource file to
the .exe file produced by the compiler. This second step
creates a combined file and tags it as executable.

The above description shows how elementary development
steps if you use the Windows 2.x/3.x SDK only. There
are other tools which simplify and/or enhance the 
procedure. Borlands resource workshop, for example,
is able to edit the resource part of an executable
in place, or to decompile it back into its parts and
into a script. 

>>>And I meant that programs can't edit their own resources, or use
>>>resources in the files they make. They are actually rather handy
>>>little things.
>>
>>A program can of course use resources contained in its load module.
>>I don't see why it shouldn't be able to modify them. It may be
>>a bit more tricky than on the Mac, and not in common use, because
>>of that. But I fail to see the Macintoshs big advantage here.
>>

>Editing your own resource fork is not a hot idea, on the Mac. It makes
>your app unsharable. However it can be usefull sometimes, if sharing
>is not a concern. Its one rather simple way to make those "type in your
>name and registration number so I can weld it to your about box" dialogs
>work- you really change the dialog.

Hm. Perhaps it wasn't such a bad idea that the Windows API doesn't
contain calls to modify resources ...

>But resources are usefull things to use for your data files, documents, etc.
>They let you organize your files so that you *or anyone else* can ADD resources
>without mucking up anything or anyone!

>This is how you can do tricks like add a "preview" to graphic images,
>so you can see what they look like in a standard file dialog. It also makes
>it easy to add things to standard file formats- just add resources. Or
>extent your own file formats.

>This is what I meant about using resources in the files they make.

I see your point. No, for data files, Windows doesn't have something
similar to Macintosh resources. Windows/NT will have NTFS, which has
extended attributes and multiple streams. But Windows/OT is clearly
inferiour here.

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