From: johnsd2@vccnw07.its.rpi.edu.its1 (Daniel Norman Johnson)
Newsgroups: comp.os.ms-windows.advocacy
Subject: Re: Macintosh bigots
Date: 16 Nov 92 00:16:44 GMT
Article-I.D.: rpi.6dv1j!j
Reply-To: johnsd2@vccnw07.its.rpi.edu.its1
Organization: Sun Microsystems, Inc.

In article 721855430@gmd.de, strobl@gmd.de (Wolfgang Strobl) writes:
>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? :-)

Yes. It was a good one. (it was also a bit truer than I'd like.. :) )

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

No! Come on this isn't that hard. You DO have that option; but it
should NOT be necessary to have an accelerator; it should be fast
enough by itself. (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...)

[deletia- Windows is based on 24 bits always?]

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

Yes, I know that. (on the Mac its 3*16 bits, so Im still waiting
for a 48 bit color board. :) )

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

Well, then, what's all this about accelerated video boards? Windows
has always seemed sluggish to me at 4 bits deep, but this is just
anectodal. I assumed that since nobody challenged that perception
(until now) it was true!

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

Ok. That's nice, but I dont see how it connects to this. (but I hate
flicker too..)

[details about Metafiles]

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

Well, then I take back most of what I said about Windows not having
a PICT equivalent. (its a shame it doens't have a metafile resource
type but that isn't a big deal)

Other questions: Does it include resultion info? Does it track fonts
by name? [just curious, this detail junk isnt that important]

[deletia- metafiles again]
>
>>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.

Which woudl those be? I dont think X has such a thing, I know
display postscript does, and (now) I know the windows GDI does. (is
this new with 3.1 or something, or did just miss it somehow?) Does
PM? What else? [can you say "off topic?" :) ]

[deletia=- sounds]
>>>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.

I was actually refering to the Windows support mostly. I know you
can hack the speaker to do things. I dont generally count
stuff that isn't part of the Official Distribution, because if you
do that so can we and pretty soon it gets rediculous. (for instance,
now I can claim that the mac has a CLI- the MPW shell. :( )

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

Hmm, I haven't noticed more that a couple.

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

No, but most do. NuBus is 32 bit. I think the PDS slots are all also
32 bits. The LC and LC II have 16 bit data paths, but I believe
they have a separate (32 bit) path to the video ram (which is separate
in them)

The IIci uses main memory for its  video (which is a slow way to do it)
and has a 32 bit data path there. I think the IIsi does to, but Im not
sure about that- it may be 16 bit, in which it would have a skinny
path to its video.

[deletia- accelerated cards]
>>>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.

Ah; Are they cheap compared to non-accelerated cards? (I would be
slightly surprised if this were so. No, make that stunned)

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

Ah; most Mac accelerated cards Ive seen are designed to be 24
bits deep. For 8 bits deep its not really worth it.

[deletia- windows is not crash-happy unles you multitask too much]
>>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.

Why does this make a difference? I dont quite see it.

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

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?

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

Well, I missed you. Ive heard that it is crashhappy but it doesn't
seem to crash much on me. (but I dont use it much either)

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

Oh, ok.

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

Really? Well, thats odd. All the books on Windows progging Ive
seen talk about separate resource files. I didn't know they
were merged, and Ive never seen a windows program with just one file.

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

I dont quite see how this works. Where do the resources
go? ARe they appended to the end or something?

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

Because Im too cheap? :)

Ill take a look if I can find a copy of this book.

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

That's not a conclusion; its one of the assumtions (well two
of them)

[deletia- details about this stuff]
>>>>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 ...

Hmm? Me no get it.

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

Just what are extended attributes? Ive heard of them, and they
sounded a little like resources, but I didn't quite get it.

---
			- 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.
Newsgroups: comp.os.ms-windows.advocacy