Re: Drag it to the trash...

Daniel Johnson wrote:

"GreyCloud" <mist@xxxxxxxxxxx> wrote in message news:X5GdnQQRMZ3rJs7ZnZ2dnUVZ_t-dnZ2d@xxxxxxxxxxxxxx

Daniel Johnson wrote:

I don't think such software exists. Other systems don't do roaming
profiles like this; your home directory may be remote, but if remote
it stays remote: a local copy is not made.

Why would anyone want a local copy of a remote?


Because it is faster. You can eliminate the network
overhead when accessing preferences and other local
data. How big a difference this makes depends on the
app, but it's always going to be faster to some degree.

[snip]

This concept has a really long history. I don't know who
came up with these session initialization scripts, but it's
still a bad idea for an end-user system.

Why? I do not see any problems in this. Seems to have worked for everyone that uses VMS anyways. MS-DOS worked fine for what it was intended for and was actually quite simple.


VMS was a minicomputer OS, and was aimed at much more
sophisticated users than Windows or Mac OS X is. You could
ask such users to write these scripts themselves.

MS-DOS was also very lame, and there was no reliable way
to install things in AUTOEXEC.BAT either, even though
DOS batch files are at least much simpler than DCL. Human
intervention was still too often needed.

[snip]

He could have found this diving in many different dumpsters.

No, just the company he was getting some online time with as a teenager.
The company at the time was using a TOPS system from DEC. The agreement was that if Bill could find a bug they'd give him free access. He found bugs and got a lot of free time. Funny he can't do that with his own o/s.


What do you mean? He finds *lots* of bugs in Windows. How do you
think they keep Windows Update so busy? :D

[snip]

The kernel seems a very strange place to put this, really.


But it has always been secure and never caused any problems. Someone could ask David Cutler at M$ tho. It was his design after all.


I suspect it was not really in the kernel at all. Putting your
command interpreter there would be very strange, and it
would be even stranger to put just a few constants there.

[snip]

This is interesting, but a little clumsy next to mount-points, I think.

Not clumsy at all. DCL is an english oriented language to most extents.


I've used it. It's a conventional batch language. It is much less
English-like than, say, AppleScript- or even COBOL.

It is English-like compared to bash, but then, what isn't?


Node names on clusters are easy to implement: BERT::ERNIE[DUA0:HISDIRECTORY] And when it comes to programming, it becomes very easy and straightforward to use.


The *naming* isn't easy to use: it's very complex. This was always
a weakness in VMS: they made their paths so complex they made
DOS look simple. Unix had this one right.


A lot of MSDOS programmers entering into the VMS system schools abhorred vms at first, but later it sank in to just how flexible the system was designed to be.
The above node name is from BERT to ERNIE on drive dua0 in the hisdirectory.


It's a lot better than DOS in most respects. But I do not understand what
it means for a node to be "from BERT to ERNIE". Can you explain
this for me?

[snip]

That's not terribly special; most shells support some sort of
aliasing.

But back in the early 80s?


I believe so. Nearly any such CLI can do this one way
or another. Even early *DOS* could do it, though not
conveniently or efficiently. (doskey was introduced in DOS 5,
1991- before that you needed to setup batch files to
do this sort of thing)

[snip]

This confronts the user with a small program in a scripting language,
and expects him to edit it. It's completely infeasable for typical
end-users.

It never was in any VMS environments. DCL is easy once you get used to it.


You are kidding yourself here. No scripting language, not even very
firendly ones, is acceptable to typical desktop computer users.


Besides, the user can just make a request and the sysadmins job is to write a SYS$LOGIN file anyways. They are usually quite short, so it isn't no big deal here.


This can work, but both users and admins dislike this arrangement intensly;
users don't get the instant gratification they crave, and admins get more
drudge-work to do.

[snip]

That they are text files is not the point; if this installer tries to edit
SYS$LOGIN, it is editing a script and it must understand the logic
of the script to do so. This is not possible in general, and so the
installation can't be done reliably.

It is possible in DCL. I've seen done many times.


How?

I wager any installers you've seen that do this automatically just
append some lines to the end of the file and hope they get
executed.


Ever see a rolling o/s upgrade? It will upgrade the o/s, only modify user written files where it needs to, and adds what it needs to systartyp.com. It works the first time always. I've never had a problem with a rolling upgrade on vms.


Presumably it only hits one of these scripts, and that one is under
admin control so users can't muck it up.

If the admin is sensible he will keep it simple and be aware of the
limits of the installer, so that it will work.

Even then, I expect it is problematic to *uninstall* one of
these things.

[snip]

That's because of the software. VMS has a very nice security
architecture. But you do not need more than 2 levels of access
in hardware to do all that.

The hardware does more than just security tho.


Well of course: it also runs your programs. :D


Part of security here is to keep things running smoothly, not just to keep out hackers.


That's an abuse of the term. You mean "reliability" or something
like that.


If a memory location starts to go haywire, then the hardware system flags the kernel to write an error message and info to the error.log file. Same for the hard drives and also reroutes data around flawed areas.


Windows actually does this for disk sectors, if the disk controller
supports it. It does not do it for memory; that just produces
a Blue Screen of Death (tm).

There are useful feaures, but not security related. And we've
certainly wander far from uninstallers!


What it does will slow the system down when hardware starts to fail, which is usually the first indicator to the sysadmin to read the error.log. Also, the priviledges are more fine tuned to cover various areas of the o/s. Instead of just two areas you have five. Mailbox priviledge, Operator privilege, memory quota priviledge, drive space priviledge, and communications privileges to name a few.


There were surely more than 5 of *these*. But what you have
described is *exactly* how Windows works.

(This is, of course, no coincidence)


The o/s and the hardware are very closely married, and this was one of the main problems for some buyers that thought they could get a cheaper deal by buying third party hardware. Sometimes, when DEC made an o/s change, there was usually a hardware change as well... they called them ECOs. So it paid to stay with DEC all the way.


That's certainly unattractive. But DEC did eventually get the beast
running on non-DEC hardware, I think was that not what OpenVMS
did?

[snip]

Yes, that's the way it works. There's a reason why Bill & Co ripped
of VMS, not Unix. :D

Bill liked DEC hardware. Can't say that I blame him. He even used DEC hardware inside M$ till the mid 90s.


Sure. He apparently also liked DEC software, judging by the
way Windows NT turned out.

[snip]

Still, users generally do *not* like customizability if it comes
at the expense of good UI to start with. They want something
friendly that they can then customize.

That's why people bought into DEC hardware and software. Customization was easy.


But it was anything but user-friendly. VMS was a strictly old-school
timesharing OS.

They didn't get a GUI at all until the adopted X-Windows.

[snip]

However, VFAT is not journaled. The default filesystem on XP
is NTFS, but you might chose to use VFAT (say, for Mac OS X
compatibility). If you do this, it is not very reliable and anything
built on it wil also be unreliable- registry included.

So what is compatible with NTFS then? I never heard anyone say that NTFS was a journaled file system before.


Then you have not been listening; it is and has always been,
and I have flogged this point myself on various advocacy
groups. :D

*Windows* is compatible with NTFS; no other OS really is
completely compatible with it.

[snip]

Yes. NTFS has had journalling in since day one. Mac OS X
was actually quite late to this game.

OS X was late to the game anyways,


Admittedly so.


but they made it quite a bit easier than anybody else.


I fail to see how. With Windows it's completely
transparent; it's just there, always on.


The VMS journalling is quite a bit more extensive tho. When I was editing a file in VMS the power went out. When the power came on I typed in edit/recover and every last keystroke entered was still there and nothing lost. I don't think even OS X or anybody else does that yet.


This can be implemeneted on any journalled filesystem; but most
apps don't try. It's not trivial, and the OS can't do it entirely
unaided.

VMS *did* have one nifty feature related to this though: it
kept old versions of your files as you changed them. Thus,
if the content of a file were damaged by the power outage,
you had a decent chance of recovering and old version that
was good.

This requries user intervention, but it works with zero application
support. Microsoft did not copy this feature; their nearest equivalent
is OLE structure storage, which is automatic and transparent to users,
but whcih requires explicit application support.

[snip]

Text files may be encoded in many ways. You may think
they are simple and trivial, because to the user they seem
transpaent, but it's not so.

Still, it is not indexed or have a certain file format to adhere to.


Prefs files typically *do* have a certain file format; they typically
are not indexed, but they *could* be. It's just that prefs are so
small it's not worth the bother.


If I store an ASCII A or and EBCDIC A it is still not dependent on anything else.


You won't be able to read the file until you know whether it's
EBCDIC or ASCII. There's quite a lot of complexity involved
in "plain" text.


That is why XML files start off with that <?...> header. If
you know the first characters of the file are <?, you can
autodetect the encoding.

And all in ASCII.


No, XML does not allow ASCII exactly.

This is *another* clever trick that we do to make plaintext
seem simple to users.

If you see the bytes <? in ASCII at the start of the file, you
are to assume that it is really UTF-8. The works because
ASCII is a 7-bit encoding, and Unicode code poins 0-127
just happen to match ASCII. True ASCII is therefore
appears to be a stunted subset of UTF-8.

It works as long as you really are using ASCII, not
one of the ISO-Latin character sets or the DOS or Mac
character sets of yore. Those will break it; there's only
so much cleverness in XML.

And XML has a lot more cleverness in it that most
text-file based formats do!


These aren't dependent on anything else other than a secondary program to decode it. There are no file structures relying on more structures to decode the file contents. If you can do a raw print out and still read it, you have ascii.


This is also not the case. XML has lots of internal structure, and
XML documents are supposed to reference separate schema files
that describe their content, and allow it to be validated.

This part is often ignored, since it makes it too hard for
humans to edit all this.

[snip]

From that point of view, yes, but not being able to be corrupted without

human interference. I'm thinking along the lines of having a file open and then the power goes out.

It is possible to do (small) text files in such a way as to protect
them from this- you write your changes into a new copy first,
flush them, and then swap the new and old files. This last operation
is protected by the filesystem journal, and so you are safe.

But the written file is on the hard drive. The only problem of ascii corruption is if the head bangs the platter in the right place and causes damages. The damage can come while the file is in memory.
But the chances of saving a corrupted memory image is very rare.


Well, no: if you manage to write only half the file out, then the
result is corrupted and can't be used. That's why we do the
write-and-swap trick.

It would be very strange for any program to keep a memory image
of a text file; it's a terribly nasty format to access in code. Better
to parse it into some more convenient structure, then regerate the
text when writing out. This has the side effect of failing if the
in-memory structure is corrupted.

The filesystem's cache of the text-files bytes is, of course,
protected by the OS from app interference.

[snip]

(For the object registrations- which is really the raison d'etre for
the registry in the first place- it won't. There are a lot of them!)

That's the part that I never agreed with anyways. At least on older systems, as this just slowed the system down terribly.


Well, yes, there is some overhead to running your objects through
the registry like this. But it's very empowering from a software
design point of view.

Anyway, putting object registrations in a text file would be
much, much worse.


A text file won't corrupt. I've never seen one yet that did it.

I certainly have. For instance, one client broke his IIS web.config
file. It was an XML file, and he accidentally typed a single space
at the start- right before the <?. This defeated encoding detector,
and the file could no longer be read.

But at least it could be fixed by hand then.


Sure, once you figure it out. We had to obtian a copy of the
file before we managed to; the client never mentioned (and
probably never noticed) this change.

Users do learn that whitespace isn't significant. They never
learn the real rule: Whitespace isn't significant.. until it is.


That isn't my meaning of corruption... in this case I call it a human screw up on a file that depends on another program to be used correctly.


You are just defining the problem away. You can call it
a Fruit Smoothie and it's still as big a problem.


ISAM files use ascii characters too, but they aren't considerd ascii text files.


Quite. They have binary structure.

[snip]

Text files usually have *lots* of things of this sort you can
break.

I think you're confusing straight text files and schemas.


*Any* text file that is to be read by a computer must have
some sort of structure to it. Even the simplest formats
do. Even tab-delimited text files with no headers may be
broken if a user deletes a tab and replaces it with a space-
which may well look identical on his screen.

[snip]

Had they been text files, they would also have been corrupted in
the same way- they are surely too big to do the 'rewrite and swap'
trick.

erm... not text ascii files. Once on the harddrive, how are they going to get corrupted if someother piece of information hasn't been flushed from the buffers yet?


Well, if you don't 'rewrite and swap' that means you are updating the
file in place or rewriting it in place. In either case, if you get halfway
through you wind up with a file that is mangled or truncated.

I'm not sure what's mysterious about this. Imaging what you'd
get if you chopped off the last 512 characters of a prefs file.

Consider that, with text files, a change early in the file typically
means *every single byte* after that point is altered (mostly by
being shifted forward or backwards within the file).


Worse, if the memory got glitched that controls the registry then the registry gets corrupted and does happen.


Bad memory will defeat virtually any program. Even text files
get cached by the OS, and if the OS's buffers get 'glitched',
your text files can be corrupted.

I've had a computer fail in this way, and both the registry
and my source code got trashed over time.


Text files that are already in existence on a hard drive do not depend on any encoding schemas. Hence if any mods to the file are done in memory... and if the memory buffer does not get flushed back to the text file, the text file isn't modified.
This is what I'm getting at.


Text files are *frequently* bigger than one disk sector; rewriting
them is *not* atomic. You can easily have one buffer flushed and
another not, unless you take precautions.

The precautions are not real hard for small text files, like
prefs. Apple's software is, I presume, doing this all for you
anyway (provide that you use it).

But precautions can also protect binary files. If anything
they are easier, because you need not support direct
human editing of the file.

[snip]

If it can be done, it would be nice for MS to include it as
a standard feature!

It would indeed. I know IBM had a rebuild command for their ISAM file system. It could possibly be done if the registry had a side file that held the definitions of the entries or a dictionary of some kind.


The registry *is* a side file that holds a dictionary of
some kind. :D

I've occasionally discussed alternative designs that use
something like Spotlight to build or rebuild a registry-like
database. The tricky part is security: not letting malicious
code that happens to be on the hard drive put itself
in the registry.

[snip- registry implement through filesystem.]

But simplicity is all you'd gain.

But enough to make it easier to fix. Its best to keep things simple if you can.


Simplificty has its benefits, but the typical problem the
registry has is *bad data stored in it*; and fixing this
would look *exactly the same as it does now*; you'd
stil have regedit and everything.

[snip]

Ok. I went thru that learning visual C++ a long time ago about serialization of files.
Not sure I like the approach tho.

Well, you wouldn't be much of a MS-basher if you
*did* like it, now would you?


Not so much of a basher as I am against their business practices.


Well, Practice Makes Perfect, you know. Keep at it- you'll
get the hang of it!


What if you owned your own software company that specialized in rebuilding registries and Gates used his methods to either run you out of business or try to buy you out cheap?


Such is life in the big city.

But bear in mind that if he "buys you out", you win- monetarily at least.
The risk is that he won't: he might try to introduce a competing product
and drive you from the market that way.

These risks are not particularly special to Microsoft, of course.

[snip]

Like all things, according to Murphys' law, it will happen.
The cure at least is easy.

The cure is the same on Windows.

What is that, dragging the registry to the trash? :-D


No, no, dragging the *caches* to the trash. :D

[snip]

You should put them in your local temp directory. This way
the disk cleanup tool can, in theory, delete them for you.

You got that right... in theory, but the one on my old IBM doesn't.
I did a deltree /y c:\windows\tempor~1 and all it does is hang.


That's not the cleanup tool I meant; there's a GUI one in
the "Accessories" directory of your start menu.


On the old HP it runs ok.


Sounds like something is wrong with your "old IBM".

[snip]

Well, depending on what you mean by "real graphics".

Real in the sense of photo quality pictures on display.


The Amiga could not do this quite. They had a very
strange graphics mode that *almost* did true-color
graphics, but not quite.


At the time there wasn't anything from M$ in 1987 that did this. You pretty much just had the cli from MS.


By 1987, MS had Windows 2. This was still not good enough,
but they were making progress.


The Amiga had advanced (for the time) graphics hardware
but hardly any software to drive it; programs that wanted to
use it had to access the hardware directly.

Wasn't that hard and was very well documented.
That's why the games were superb above the rest.
M$ at that time didn't have anything near it.


MS was not a hardware manufacturer- except for
mice, back then, I think. MS had *software* that
could drive most of the Amigas graphics hardware
(that almost-true-color mode would have been a
problem)

But Windows would not available on the Amiga, so
this did not do any good.

[snip]

Had they been able to run *Apple's* OS on their
box, they might have done better. Apple had made
the *real* breakthrough: their platform was done entirely
in software, which proved far more flexible.

But never produced the same quality of color graphics that the Amiga had.


It eventually beat it, once Apple's hardware had caught up. It
did do that eventually; I believe the first 3rd party 'true color'
cards for the Mac appears in the late 80s. Of course today,
nobody- not even cheap PC cloners- ships anything *less*
than true color. With accelerated 3d, yet.


Even todays OS X speech isn't as good as the Amiga speech synthesis.


I am not familiar with this aspect of the Amiga, so I cannot
comment, but I will anyway: I suspect this is a subjective
judgement.

[snip]

Neither of these was in any way an innovation. *Segments*
were the innovation, but not all innovation is good. :D

The segments were a PITA to good programming practices.
Also caused a lot of problems.


Yes, absolutely.

[snip- agreement]

Hmm.

You seem to be using 'stagnation' differently than I would.

I know of an M$ programmer that had quit... said it got pretty boring.
That's what stagnation is my view. When it gets boring.


Hmmm.

Well, I think that's not a reasoable definition of
"stagnation". I agree that the current industry is
boring, and the more MS dominates it, the more
boring it is.

But bear in mind that what most customers want
is improved technology to solve their problems,
not drama. The PC wars of the 80s were exciting
and made good copy, but they did not serve the
interests of the end-user very much.

[snip]

I see the '80s as a period of stagnation because clever
new technologies were 'blocked' by compatibility
concerns. The great new inventions got bottled up,
because to use them you had to sacrifice all your
existing hardware and software.

When IBM brought out the PC is when the stagnation started.


I would not say that. I would date it to the Great Price War
in the mid-80s. That's when most of the diversity died;
after that you still had Commodore, Apple and a zillion
cloners- but before that you had many, many more viable
platforms.


For a while the Ataris and Amigas gave a breath of new life.


Atari and Commodore tried to bring out 'next generation'
machines, but they never could really make it work. Commodore
came closest, and lasted longest, but in the end the Amiga could
never take the place of the C-64.


Then we have windows... and nothing has really changed.


On the contrary; the industry is structured differently now. There
one major platform, Windows, and nearly everything is structured
around this; new technologies and products can come and go
*without* any major disruption, now.

The only rememant of the old days is Apple, and that's a very small
slice of the market.


Gates dropped Fortran, Cobol, and Pascal and kept C/C++/Basic. Now that is boring.


I do not understand what you mean by this. What could be
more boring than COBOL? :D


Remember that Commodore is dead, and they
died shortly after the *C64* become unviable.
The Amiga.. didn't matter.

The company was trying to compete against MS DOS at the time with its own clone. From what I've read, it was the Amiga sales that kept the companies nose above water... for a while. It was just bad management.


Yes, as I understand Commodore had bad management. But
nearly *all* the early computer platforms and their makers
perished; they can't all have had Commodore's management
team. :D


They clever hardware was great, but it could not
overcome the burden of incompatibility.

Incompatibility really wasn't the issue. It was more bad management than anything else.


I credit the compatibility issue with the failure of most of the
next-generation machines. Only Apple really managed to get
past it, and only then at a considerable cost in marketshare.

Commodore was not unique. Many vendors came out with
next-generation products that could not use the previous
generations software or peripherals. And they failed.

The PC has been very different. It's still *called* a IBM
PC clone, but the hardware and software have been
*entirely* retooled. PCI instead of ISA; USB instead
of serial ports; all kinds of swanky accelerated graphics;
fancy pants sound; we've changed instruction sets
three times so far, and the fourth shift (to x64) is
underway right now.

That is entirely remarkable, when compared with any
other platform.

[snip]

It is true that there is not much room for innovation at the
core OS level; the NT kernel is pretty much like the
VMS one, and there are powerful forces that make it
very, very hard to anyone, even Microsoft, to change it
in any large way.

David Cutler wants M$ to go the AMD64 route. Don't know how that is faring for him.


What do you mean? Microsoft *is now shipping* x64 versions
of its OS. Even Intel now supports AMD's new instruction set;
the writing appears to be on the wall on this one.

This will be the *fourth* ISA upgrade for the platform.

[snip]

They work just as well as "real" modems but are cheaper;
they are possible *because* the relevant part of the market
has written of Unix.

But you need windows to run them. A hardware modem runs better but it will also run on any platform.


This is exactly the tradeoff the market has made: having only one
platform makes everything else easier and cheaper.

[snip]

3D revolution in Gaming? I think the Amiga got started there first.

The Amiga did not have 3d graphics; it had
accelerated 2d graphics.

Oh, it did have it. It had the bit planes. I don't see this anywhere else except on high end graphics systems.


I am not following you. What do bit planes have to
do with it?

[snip]

So? Amiga was Amiga, not a C64.


<Yoda>
That... is why it fails.
</Yoda>

This happened because Commodore had nothing
like Windows.

Yeah, because windows wasn't out yet.
Amiga did have a windowing gui.


It lacked the "underpinnings" as we now call them;
it did not provide a software layer for all the
hardware, or one that would all new hardware to
be installed and used transparently.

Apple *did*. Their design was flawed in some ways,
but it achieved the coverage needed to allow
backwards compatibility *in software*. Its flaws
could be (and were) hacked around. The Mac II
was only possible because of this.

Microsoft did even more; their API was designed
with future hardware in mind, so that Windows
programs would be able to use upgraded hardware
as soon as it came out, without being modified to it.

That really lubricates the wheels of progress. It
means that a vendor who ships an improved graphics
card or printer or whatever can win customers
*today*.

[snip]

This left the field open for someone else to do what
needed to be done, and that someone was Bill.

Hehe... actually it wasn't just bill alone... it was DEC, IBM, HP, SGI, Sun. They all got in on the development of Motif and some of the widget headers have M$ copyright notices in them.


Well, no. It was mostly Bill & Co. Motif was a UI toolkit,
and a really bad one. The Amiga had that. That is not the
point.

[sip]

What do you mean?

Where several layers of background had different perspectives. And then the added sprites for gamers. The various levels of backgrounds moved around to give it a 3D look.


I can't believe you are calling that "true 3D".

[snip]

Maybe; but had they done so they'd still have been blocked
by compatibility.

Compatibility with what? It's own line?


Exactly!


Are programs written for win3.1 compatible with XP today? Nope.


Like hell they aren't!

You can indeed run Win3 programs. And they run better
than they did on Win3; They are memory protected and
pre-emptively multitasked; they can allocate many more
handles on modern hardware. They can allocate
(a little) more memory. They can draw in true-color.

If you want to try it, there should be a C:\Windows\Winhelp.exe
installed on any XP system. This is the 16-bit help viewer


So the compatibility argument doesn't really hold any water here.
I'd say that compatibility is a form of stagnation if it lasts too long.


I am sure you do- it is, after all, boring, boring, boring!


The fancy new hardware would have to
be able to emulate the old, making it more expensive. The
old software would not take advantage of it, making it no
more desirable (at first) than the cheaper old stuff. The
new software, if any, would not work on the old hardware
(so developers would be reluctant to write it at all).

But they have done that already in the past. That's what breaks stagnation. After a while it become ho-hum and people will move on to other things.


They don't do it much anymore, because there is a better
alternative- the Windows PC.


To actually *deliver* on these innovations, you need
something to break this deadlock. Windows does that.

I don't see how they do. If anything, the majority of M$ products are the same as those produced 10 years ago. Nothing really new.


I have explained this. I think what remains is mere denial.

[snip]

Whose technology? Sure isn't from M$.

Sure is: GDI16 was the tehnology that made this possible
on the PC.


GDI16??


Yep.


Uh... done by graphics card vendors.
If they weren't capable of building the hardware it wouldn't be.


They built the hardware; GDI16 is the API
programs used to access it.

[snip]

But without the software, there were very serious
obstacles to their adoption. Why pay for a high-res
screen if you can only drive it at 320x200 in a
compatibility mode?

That was an o/s vendor problem.


... Microsoft was the O/S vendor that solved it.


when I had win3.1 I paid extra for a high res screen and software.
DEC made it independent of the o/s thru the use of dedicated terminals.


I do not see what you are getting at. I am familiar with
DEC's line of terminals in a vague way; I still remember
the VT100s from school.

In a small way, it recalled the situation on early PCs;
software would target a specific terminal or set of
terminals and would not work on other, incompatible
terminals.

So DEC shipped a library (I forget what it was called)
that provided drawing services that would work on
any terminal; programs that used this library would
be "terminal independent". But they would not be
OS independent; they would run on VMS only.

[snip- scroll wheels]

The thing is, without Windows, how do you implement
such a thing so that it actually works? Here emulating
the old hardware isn't the big problem, it's getting apps
to implement scroll wheel support. An OS like Windows
can do that globally.

Actually, you don't an o/s to do that.


I don't?


Of course it vectors into hardware design and becomes independent of the o/s. Had track balls on old radar systems that worked pretty good and were quite accurate for the job. It all depends on whether you need it or not. And in the case of any o/s... they all now support this, so it isn't just windows alone that can accomodate this feature.


Well, Mac OS X supports it and works it much the same way
Windows does, except they have to do these things twice, once
in Carbon and once in Cocoa.

Unix systems suffer from a plethora of different APIs for this kind
of thing; scroll wheel support must be implemented in *each*,
plus in any program that "rolls its own"- mainly the ones that predate
the modern Unix UI toolkits.

Uh... The API list in windows is pretty good sized one as well.
Actually, when using Motif, the program for just the window and a push button is much smaller than the windows counterpart. You can find "Programming in Motif" on the net. It has to do with the callback function and message event handling. But the eventual code size is about the same. There are benefits tho to using the windows APIs as they are a bit more flexible than the Motif/CDE way of doing things.

Any ways, it has been enjoyable talking with you... my short vacation from care-giving has ended and back to task of care-giving. It's a long hard job and one I don't like doing but I have no choice.


This makes it much harder, though admittedly it's an improvement
over the bad old days!




--
Where are we going?
And why am I in this handbasket?
.

Quantcast