Re: Drag it to the trash...

Daniel Johnson wrote:

"GreyCloud" <mist@xxxxxxxxxxx> wrote in message news:NpWdnXA6sruPG8_ZRVn-ig@xxxxxxxxxxxxxx

Daniel Johnson wrote:

Even if an admin is willing to do that, finding roaming
profiles is not possible, so he can only get the ones that
do not roam.

There might be a piece of software utility out there to help in finding and administering these "roaming profiles" for windows.
Not exactly what I'd expect tho. Other systems don't have that problem.


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?

[snip]

That's like DOS's AUTOEXEC.BAT!

Which Gates copied from DEC.


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.



And history shows that Bill did do some dumpster diving in Bellevue when he was a lad. Of course the DEC DCL is quite a bit more advanced and comprehensive than dos was.


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.


The DEC system hardwired some names to the kernel. These are SYS$LOGIN.COM, SYS$STARTUP.COM, SYS$LOGICALNAMES,
and a few more that can't make it thru to the top.


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.


Hard drives are somewhat prewired by name to an extent, like DMA0: or DMA1:, MUA0: etc. But then the user can just poke into his own sys$login.com file as alias : $ DMA0: == Bert. Then when he needs to make a sub directory, all he has to do is use CREATE/DIR [Bert:mydirectory].


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


There are a lot of things one can do, but if it goes too far it can get confusing with too many aliases. Even the DCL commands dictionary can be customized for the end user by deleting most of the commands you don't want them to have access to or by renaming some commands that fit the users needs. And its all in text form.


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


But back in the early 80s?


These sorts of files are not "plain text"; they are *programs*
(written in DCL I should think) and expecting installers to modify them
is a bit much. Expecting ordinary users to do so is out of the question.

No, just plain text files. You have to realize that the VMS file system is ISAM by default if you need to access things in a sorted order.


Yes, I know about RMS. They did not store these files in
such a form; had they done so, it would not have worked since
the program the script encodes would have executed out of order.


But all one has to do from a terminal is type in EDIT SYS$LOGIN and the file appears onscreen. A normal text editor. No installation program at all.


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


When the sysadmin loads a new large commercial program onto a vms system, the so called installer is basically just a script that has been given priviledges to create files and directories, make changes to the system logical tables, and creating new aliases. But these are all text files.


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


[snip]

This is really sort of archaic. It's a lot of complexity for no real
benefit; you only need 2 levels in hardware and you can do everything
else in software, where you can at least fix the bugs.

It still qualifies for the higher levels of certs than any UNIX system can attain.


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. Part of security here is to keep things running smoothly, not just to keep out hackers. 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. 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. 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.


VMS is really for those companies that need hard security at the system level and yet the company must also add physical security to attain an A level.


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.


Most of my sysadmin techniques relied on programming a dedicated terminals function keys to do different tasks... by logging in and pushing the correct (1) function key.

That is pretty poor UI by modern standards, of course.

From a terminal it allows the user to customize things to their own needs,
not hardwired by someone else that thinks that is what you need.
Each installation is going to be different.


That is, of course, a tech-support problem. Yet users do desire
it; one wants to strike a balance here.

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.


[snip]

This is *not* true. Databases are very corruption-resistant
because of the journalling techniques they use.

Well then, is the registry journalled and is XP a journaling file system?


Yes to both.

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.



I know that Linux 2.6 using ResierFS is journaling. So is VMS.
As well as Tiger.


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, but they made it quite a bit easier than anybody else. 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.



Even non-database-like binary files are more robust than text
files as a rule. Text files are more complex so that they may be
made human-readable: they support comments and
non-significant whitespace. They must tolerate ASCII,
UTF-8, UTF-16, and gawd knows what other encodings.

Uh, that is what text files are... straight ASCII.


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.
If I store an ASCII A or and EBCDIC A it is still not dependent on anything else.


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



Worse, human-readable files are almost always seen as
human-writable first. The text file can easily be *structurally*
corrupted by a careless user. And even careful users make
mistakes sometimes.

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.

But you can do that with binary files, and with binary files it's
possible to implement transactions. You need to design your
format properly, but there's no mystery to it.

If your files are *large*, then of course text files won't scale
for this and other reasons, and you have to go binary. But
for preferences, text will do.


The prefs files are small anyways.

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


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. 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.
ISAM files use ascii characters too, but they aren't considerd ascii text files.


With the registry, he could not have done that.

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

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



I've seen IBM ISAM files get easily corrupted from a power failure.


Well, presumably that database does not support transactions,
and IBM keeps it around for compatibility.

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?
Worse, if the memory got glitched that controls the registry then the registry gets corrupted and does happen.

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.


[snip]

No. This is the great weakness of the design. This is why
you sometimes really do need to rebuild a Windows system
from scratch.

Sounds like an opportunity for a programmer to make one.
Would be very helpful for those that have to work with windows.


Yes, but how do you implement it?


I wouldn't know, but I bet some bright individual out there will if there is a need.

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.


[snip- text vs binary again]

Except that prefs are individual and go with the app.
There isn't a central registry that gets involved.

Prefs files do not go with the app: they go in your
~/Library/Preferences directory. They aren't all
kept in one file, but this does not make any difference
since they *are* all in the same directory.

Everything technically is in one directory... the hard drive. If it fails everything goes.


Very true.

Consider this: you could 'split out' the registry into
the filesystem, so that each key is a directory and
the values could be stored in a file. Perhaps a plist-like
file even. :D


That might work well.

The registry APIs could be rewritten to access these
direcetories. This would simplify the implementation
since a large part of what the registry does is already
done by the 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.

Both systems boil down to
a block of bytes in the end, and both must explicitly
implement a lot of stuff- including journaling for safety-
on top of that.

The registry is done in a small number of larger files
because this is much more space efficient, even on
NTFS. On VFAT, with its gigantic clusters, the
wasted space of the approach I've outlined would
be monumental.

[snip]

Yes.

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


[snip]

I wonder. But maybe you do. In any case, it can't. It can
regenerate prefs like the Mac does, but the bulk of the
registry is not prefs.

I know. Things like the title bar for IE modified by AT&T.
Try and hunt down all of their modifications. A true PITA.


This kind of thing really requires an uninstaller to do.


Ah, but theirs didn't. It left so much garbage and new entries in the registry that it took me days of cleaning to get it right.

(But of course, then you are depending on AT&T to provide
one. What are the chances?)


Well, we all know that they didn't.

[snip]

It can happen, but presumably MS works a little harder to make
Windows Media Player solid on Windows.

Caches do differ from prefs in one respect: caches are about
making a program *fast*, so there is a temptation to omit validation
if it would be expensive. After all, caches are private files of
the app, no-one should be editing them. So nothing can go wrong,
right? :D

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

The registry is not suitable
for caches; it is not fast enough and cannot hold large enough
data volumes.

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.
On the old HP it runs ok.


I say "in theory" because it does not appear to actually
do this for per-user temp files, even for the user who
runs the tool. But, you know, *in principle* it could
work... :(

[snip]

Java was first released in 1996. It's still on the young
side, as languages go.

I thought it was derived from a project called OAK?
Back in the late 80s?


It's roots go much father back than that. In my opinion,
the only really *original* languages were Fortran, Lisp,
and COBOL. :D


I read about oak in the intro to Java.

However, if we 'date' languages in this way they are all
about 50 years old now. :D

And nothing really wrong with them either. Fortran is still evolving. Why? Because of the attention to numerics and accuracy and speed.
For scientific uses it is still the best if you have large amounts of numerical data to massage.


[snip]

That was when things really were stagnating.

No, that was when real graphics took off at an affordable price.


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


Real in the sense of photo quality pictures on display.
At the time there wasn't anything from M$ in 1987 that did this. You pretty much just had the cli from MS.

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.

This meant that when the next-generation Amiga came out,
Commodore had to support the old modes and behaviors
so the old software would work. It also meant that that old
software could not take advantage of the new hardware
at all.

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.
Even todays OS X speech isn't as good as the Amiga speech synthesis.

But Apple didn't have the advanced graphics hardware.


Also had multitasking and a linear address space vs the 8088.


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.

[snip- agreement]


There were still good ideas then: the Amiga's graphics
architecture, the Macs GUI. But they stayed bottled up
on niche platforms.

But that's what made it interesting. I don't want everything standardized on one platform. That just breeds monopolization
and more stagnation.


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.


I wonder what you mean by it.

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.
For a while the Ataris and Amigas gave a breath of new life.
Then we have windows... and nothing has really changed. Gates dropped Fortran, Cobol, and Pascal and kept C/C++/Basic. Now that is boring.


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.


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.

[snip]

I do not wish to exagerate MS's own innovation: but they have
been an enabler for innovation. Their software makes each hardware
and software component independent, thereby making it possible for
other vendors to produce innovative products without having
to build 'a new o/s and hardware'.

But I see this as just a new level of stagnation. IOW, everything is now made to the MS standard and leaves out any possibility of real innovation.


I do not know what you mean by "real innovation"; but
I wonder if you should call your "new level of stagnation"
something else... like say "progress". :D


What progress? I really don't see it, except some at Apple.
That's why the PC sales are starting to sag. Same old same old.

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.


Without Windows, there would be no WinModems or WinPrinters;
there would have been no 3D revolution in gaming. No 3d-sound
cards.

I don't believe that. I don't like WinModems. They don't work with UNIX. Better left in hardware.


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.


You lose one thing but gain another. It's a tradeoff.


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.

But the Amiga did have something; yet very
few users ever saw it, because it was totally
incompatible with everything else. Not just with
commodity PCs: it was incompatible even with
Commodores top seller, the redoubtable
Commodore 64.


So? Amiga was Amiga, not a C64.

This happened because Commodore had nothing
like Windows.

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


Only Apple did, at first- and Apple could have changed
the industry, but they chose* to stay bottled up on their
expensive, propriety hardware.

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.


Plus the fact that the dedicated graphics chips allowed for true 3D screens that I've yet to see in any of todays games.


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.


Amiga also had stereo sound and I'd believe that if the CEO hadn't screwed up, that they'd be the first with 3D sound.


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

Compatibility with what? It's own line?
Are programs written for win3.1 compatible with XP today? Nope.
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.

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.

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.



Even simple things like high-resolution, high-color screens are extremely
difficult without this technology.

Whose technology? Sure isn't from M$.


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

GDI16??

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


(On the Mac it was Color QuickDraw)


Remember it was their software, not the hardware that drove their market. Hi-Res screens were available long before M$ got into the fray.


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. 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 doubt we'd even have scroll wheels.

They had track balls back in the late 60s on expensive systems. The idea isn't innovative by a long shot.


Scroll wheels are not trackballs, but you can argue whether
its a "real innovation" I s'pose; I don't find much value in that
dispute.

trackballs and scrollwheels share the same action. A motion sensor and direction detection are what makes them feasible. I can do the same with a trackball that you can do with a scroll wheel and more.


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

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

Relevant Pages

  • Re: In the Shallow End
    ... When a document claims how an API is supposed to be used and then gives the user examples that actually work, ... Vague in your instance means you have no context to VMS or UNIX of that era. ... Windows offers lots of this stuff. ... That's why Apple had to dump a whole paradigm to plunge ahead and take the lead. ...
    (comp.sys.mac.advocacy)
  • Re: "Shanghai Stock Exchange" and OpenVMS
    ... Windows was shipping without any "documentation". ... "right out of the box" VMS has no applications at all. ... Guess it depends on the style of manuals you are used ... that I need to use the MS-DOS command window in the first place!)? ...
    (comp.os.vms)
  • Re: "Shanghai Stock Exchange" and OpenVMS
    ... Windows was shipping without any "documentation". ... What about VMS as a back-end? ... have never found the VMS manuals to be all that readable or easy to ... where's the secret documentation for all the MS-DOS commands, ...
    (comp.os.vms)
  • Re: PC Systems for sale
    ... These have become very popular with our customers as we can still sell NEW ... quite happy to sell desktops with Windows XP support. ... The net result was a recapture by VMS of an application at ... however not running Windows or OSX. ...
    (comp.os.vms)
  • Re: [opensuse] VMware workstation 7 and opensuse 11.2
    ... VirtualBox can read VMDKs, ... Linux VMs may require re-configuration of Xorg and hardware. ... Especially because the VM is a windows XP system. ...
    (SuSE)
Quantcast