NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/os/mswindo/advocacy/2764

Text File | 1992-11-18 | 13.5 KB | 368 lines

Newsgroups: comp.os.ms-windows.advocacy
Path: sparky!uunet!snorkelwacker.mit.edu!ira.uka.de!gmd.de!strobl
From: [e-mail] (Wolfgang Strobl)
Subject: Re: Macintosh bigots
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News)
Nntp-Posting-Host: gmdzi
Organization: GMD, Sankt Augustin, Germany
References: <[e-mail]> <r![e-mail]>
Date: Wed, 18 Nov 1992 22:49:51 GMT
Lines: 355

In <r![e-mail]> [e-mail]1 (Daniel Norman Johnson) writes:

>In article [e-mail], [e-mail] (Wolfgang Strobl) writes:
>>In <6dv1j![e-mail]> [e-mail]1 (Daniel Norman Johnson) writes:
>>
>>[...]
>>
>>>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.
>>
>>I disagree. This may be true for the Macintosh. It doesn't make
>>sense to construct an Macintosh with a video interface which
>>is not able to run the only available user interface software
>>fast enough. It makes sense to sell a PC with video hardware which
>>is more than fast enough to run in text mode or to display static
>>graphics, but which is a bit slow when used with Windows. Especially
>>if it can be replaced easily. Just throw out you old and slow VGA
>>card, and put it into one of the file servers, where display
>>speed doesn't matter at all, and buy an accelerated card for
>>your desktop PC. Not that hard, either, isn't it?

>Significanly harder in my book; why should this rigamarole be
>necessary? Particularly if all your computers are using Windows..

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

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

[...]
>[deletia- big gnarly code bit]
>>>[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?)
>>
>>GDDM, GKS, CGM, PHIGS, to name a few. X isn't exactly a graphics
>>interface.

><whimper> none of which Ive ever heard of. :(
>It would explain why I didn't know these thigns were
>that common.

>X is graphics library thingum; it ought to have such a thing.

>>No, metafiles aren't new. I don't know about version 1, because
>>I started programming for Windows with version 2.0, which already
>>had metafiles. Perhaps this should be clarified by somebody else.

>It would be a good idea.

Yes. ANYBODY OUT THERE?        ...silence...

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

>>>What else? [can you say "off topic?" :) ]
>>
>>:-)

>I knew you could!

9-)

>>>[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.
>>
>>No. This is Windows support. It is a native Windows device driver,
>>which implements the sound device of Windows 3.1. It just wasn't
>>include in the 3.1 release disk, but came later. Think of it
>>as a bug fix for the default speaker driver, if you like.

>There is no default speaker driver. If it was a bug fix, it should
>be included with the 3.1 distribution.

It should be included with the 3.2 distribution. The
multimedia support was new in 3.1.  Wait and see.

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

Sound Functions

Sound functions create sound and music for the system's sound
generator. The following list briefly describes each sound function:


Function    Description
CloseSound    Closes the play device after flushing
the voice queues and freeing the
buffers.
CountVoiceNotes    Returns the number of notes in the
specified queue.
GetThresholdEvent    Returns a long pointer to a threshold
flag.
GetThresholdStatus    Returns the threshold-event status
for each voice.
OpenSound    Opens the play device for exclusive
use.
SetSoundNoise    Sets the source and duration of a
noise from the play device.

SetVoiceAccent    Places an accent in the voice queue.
SetVoiceEnvelope    Places the voice envelope in the
voice queue.
SetVoiceNote    Places a note in the specified voice
queue.
SetVoiceQueueSize    Allocates a specified number of bytes
for the voice queue.
SetVoiceSound    Places the specified sound frequency
and durations in a voice queue.
SetVoiceThreshold    Sets the threshold level for a given
voice.

StartSound    Starts playing each voice queue.
StopSound    Stops playing all voice queues and
flushes their contents.
SyncAllVoices    Places a sync mark in each voice
queue.
WaitSoundState    Waits until the play driver enters the
specified state.

End of Quote.

The standard driver for the internal speaker supports only
one voice and only a subset of these calls (OpenSOund,
StartSound, StopSound, SetVoiceSound and a few others),
but it is sufficient to implement a lot of characteristic
sounds and noises, much more than a simple beep.


>>>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. :( )
>>
>>If it only uses a few bytes on the disk, is easily installable
>>and simple to use, why not? :-)

>Because two can play at that game. We will be comparing constantly
>moving targets.

On the other hand, comparing what a hardware *and* software
supplier offers with something from a software only seems
a bit unfair to me.

>>
>>[...]
>>>>>>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)
>>
>>No. But the current bunch of cheap accelerated video cards are
>>much more in the price range of non-accelerated cards than
>>in the range of expensive accelerated cards. I.e. you can
>>buy non-accelerated cards from 150 to 800 DM (1.6 DM == 1$),
>>cheap accelerated cards starting from 350 DM, while expensive
>>ones may easily cost 3000 DM and more. This is because the
>>latter ones where built for expensive CAD workstations
>>built from PC hardware. These cards usually came with
>>AutoCad drivers, and only just recently with Windows
>>drivers. The cheap accelerators are either one-chip
>>reimplementations of IBMs 8514 device, or where constructed
>>with Windows in mind.

>Whats the difference that makes for the price difference?

Specialization and economics of scale.

>>[...]
>>
>>>[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.
>>
>>With a separate LDT for each task, a task has only access to its
>>own data structures and those which the OS made gobally available
>>via the GDT. With a "global" LDT, each task has access to all
>>the above, and to the data structures of all other tasks, in
>>addition. In both cases, a task will get an memory access
>>fault if it uses an invalid selector number or an offset outside
>>the bounds of a valid selector. But the set of valid selectors
>>is different. In the former case, it's G+Tn for task Tn, in the
>>latter case it's G+T1+T2+..+Tn.

>Oh, so with local tables each app has teh same access any
>other app does?

With a LDT (a local descriptor table) which isn't changed
during the task switch (the WIndows method), all apps
have the same access. There is still protection - Windows
can protect its own data structures, and a task has to
know the other tasks selector numbers in order to access
that memory, but there could be more 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.

[...]

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

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

>[deletia- resources stuff]
>>>Just what are extended attributes? Ive heard of them, and they
>>>sounded a little like resources, but I didn't quite get it.
>>
>>They where invented with HPFS for OS/2 1.x. In principle, its
>>just a name=value table attached to a file. I.e. you have
>>one byte stream plus an arbitrary number of (name,value) pairs
>>in a file. NTFS generalizes this a bit, by providing multiple,
>>named and typed streams within a single file. A stream has
>>a type (data, extended attribute, security data or alternate data),
>>a size and a name. Unfortunately, the current (non-)release of
>>Windows NT doesn't implement much of this, yet.

>What can the values be? Just anything? Are the names
>strings?

As far as I know, yes, for both questions. HPFS has a
limit of 64K for the values, if I'm not mistaken.

Wolfgang Strobl
#include <std.disclaimer.hpp>