From: johnsd2@jec314.its.rpi.edu.its1 (Daniel Norman Johnson)
Subject: Re: Macintosh bigots
Reply-To: johnsd2@jec314.its.rpi.edu.its1
Organization: Sun Microsystems, Inc.
Date: Sun, 15 Nov 1992 18:00:01 GMT

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! :)

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

>>(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.)

>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?

>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.

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?

>
>>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.

>>>>> 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?

>[...]
>
>
>>[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?

>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.

[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?

>>>
>
>[...]
>
>>> 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?

>>>>>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?

[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]

[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?

I am saying that:
	- Windows programs must have SEPARATE resource files-
	  you cant put the resources in the .EXE.
	- You will virtually always need (or at least want) to use
	  resources in windows programs.
	- 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?

>>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.

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.
---
			- Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.