Old Computers Did it Better!

[n45048]

www.youtube.com/embed/0wDtxYeJdzg

Rather entertaining video but he raises some good points. ;-)

[TriodeTiger]

It was *just* good enough to make the effort of muting those transition sounds, after the 100the time. I only wish one day I can get my paws on a C64 and make a hobby of it. We should make clones of them for our future children!

[Artlav]

Hm.
Just dug up a shoeboxfull of a Windows 98 computer - it takes longer to boot up than both a Win7 PC and an Android tablet.

Seriously, one thing that really pisses me off about post-DOS computers is INSTALLING programs.
Why can't a program just run instead of needing a bunch of hidden stuff written by a separate program that is just an unpacker?
What's with the more recent fashion of putting config and data files into some obscure location in a user profile, instead of keeping them in the program's directory?
Simply speaking, why (Windows) software is not made portable by default?

Programming is also a thing that withers away, especially in the mobile market.
On WindowsCE, PocketPC, you could just write a program with whatever tools, copy it over, run it, and it works.
On Android, there is 500Mb bundle of software of all kinds and shapes that produce a program, with little to no other options. You can only program in some sort of Java, in a rather clumsy fashion. Sure, you can use GCC and C, but then be limited to console applications.
On IPad, it takes 25Gb of stuff and unknown amount of money to start programming, the language of choice is not even Java, but something completely obscure, and you can't just run a program on a phone anyway - signing needed. The silver lining is that you can relatively easily use other languages instead of their mutated C++ clone.

Just why make it so difficult?
Your platforms is nothing without developers!

[/unsolicited rant]

[Yago]

Hm.
Just dug up a shoeboxfull of a Windows 98 computer - it takes longer to boot up than both a Win7 PC and an Android tablet.

Seriously, one thing that really pisses me off about post-DOS computers is INSTALLING programs.
Why can't a program just run instead of needing a bunch of hidden stuff written by a separate program that is just an unpacker?
What's with the more recent fashion of putting config and data files into some obscure location in a user profile, instead of keeping them in the program's directory?
Simply speaking, why (Windows) software is not made portable by default?

Programming is also a thing that withers away, especially in the mobile market.
On WindowsCE, PocketPC, you could just write a program with whatever tools, copy it over, run it, and it works.
On Android, there is 500Mb bundle of software of all kinds and shapes that produce a program, with little to no other options. You can only program in some sort of Java, in a rather clumsy fashion. Sure, you can use GCC and C, but then be limited to console applications.
On IPad, it takes 25Gb of stuff and unknown amount of money to start programming, the language of choice is not even Java, but something completely obscure, and you can't just run a program on a phone anyway - signing needed. The silver lining is that you can relatively easily use other languages instead of their mutated C++ clone.

Just why make it so difficult?
Your platforms is nothing without developers!

[/unsolicited rant]

Gooooooooddd.
Let the hatred run through you, it will make you more powerful than ever imagined.
*throaty noise of life support apparatus*

  

[AG6QR]

Seriously, one thing that really pisses me off about post-DOS computers is INSTALLING programs.
Why can't a program just run instead of needing a bunch of hidden stuff written by a separate program that is just an unpacker?
What's with the more recent fashion of putting config and data files into some obscure location in a user profile, instead of keeping them in the program's directory?
Simply speaking, why (Windows) software is not made portable by default?
[/unsolicited rant]

I agree completely.  It has a lot to do with the Windows use of the registry.  But why, oh why, did the Windows architects decide that so many things critical to the functioning of every program should all be piled together into a single monsterous database, with virtually no checkpointing, no transaction support, no segmentation, virtually no protection, no ability to backup/restore along with the file system, etc.?  Every Microsoft programming technology since COM has made the registry a crucial piece of the puzzle.  The use of the registry has made it difficult or impossible to have a nontrivial program "just work" if you copy the program to a directory and run it.

As far as the issue of separating user data files from programs, it's not such a bad idea to protect someone who is running as an unprivileged user from writing to directories containing executable binary programs that may be used by other users.  That principle is fairly fundamental to security and avoiding malware, in fact.  But it was retrofitted into an operating system that never had it to begin with, and this has caused many compatibility problems.


The opportunities for ranting against Microsoft become even more numerous when you look at the solution they recommend for the problem of getting files and registry entries onto a machine.  They came up with the Microsoft Installer (MSI) technology, which uses a convoluted relational database.  The database has 100 different predefined tables in its schema, with optional additional custom tables.  All for the simple task of copying files and registry entries to a machine!

And don't get me started about the evils of the MSI patching technology!

I could rant on about how truly awful the MSI database schema is, but I'm afraid it would serve no purpose other than to make me angry.

[Corporate666]

Hm.
Just dug up a shoeboxfull of a Windows 98 computer - it takes longer to boot up than both a Win7 PC and an Android tablet.

Seriously, one thing that really pisses me off about post-DOS computers is INSTALLING programs.
Why can't a program just run instead of needing a bunch of hidden stuff written by a separate program that is just an unpacker?
What's with the more recent fashion of putting config and data files into some obscure location in a user profile, instead of keeping them in the program's directory?
Simply speaking, why (Windows) software is not made portable by default?

Programming is also a thing that withers away, especially in the mobile market.
On WindowsCE, PocketPC, you could just write a program with whatever tools, copy it over, run it, and it works.
On Android, there is 500Mb bundle of software of all kinds and shapes that produce a program, with little to no other options. You can only program in some sort of Java, in a rather clumsy fashion. Sure, you can use GCC and C, but then be limited to console applications.
On IPad, it takes 25Gb of stuff and unknown amount of money to start programming, the language of choice is not even Java, but something completely obscure, and you can't just run a program on a phone anyway - signing needed. The silver lining is that you can relatively easily use other languages instead of their mutated C++ clone.

Just why make it so difficult?
Your platforms is nothing without developers!

[/unsolicited rant]

I always thought that Windows should mandate a simple directory structure for any installed program, with a registry directory, a DLL/component directly, data directory and binary/executable directory.  Then, installing a program would essentially be putting it into a directory and adding an icon to the start menu.  And un-installing would be a matter of deleting the directory.  Plus, everything could be in one location so you don't have the ridiculous BS you mention above.

P.S. Where in Russia are you?  Been there many times... SPB, Moscow, Kazan, Saratov, Rostov, Voronezh... interesting and cool place

[SirNick]

Seriously, one thing that really pisses me off about post-DOS computers is INSTALLING programs.
Why can't a program just run instead of needing a bunch of hidden stuff written by a separate program that is just an unpacker?

Truly more laborious than it should be on Windows.  Linux can be difficult because of its modularity.  That comes with the territory, and is therefore excusable.  On Mac OS it's very often just a drag-and-drop operation -- the way it should be.  (And to uninstall, delete the icon.  Done.)

What's with the more recent fashion of putting config and data files into some obscure location in a user profile, instead of keeping them in the program's directory?

That's not recent.  In Unix/Linux land, that's the way it has been for ages.  (Although, it's not obscure -- it's your home directory, which is given much more emphasis on those platforms.)  OS X also caters to separation of programs and data.  As others have said, this is actually a much better idea than allowing users to crap all over system and program directories.  Windows at least got that right -- although the organizational scheme is pretty awful, and then there's the registry...

Ideally, you should be able to copy your "home directory" (or whatever equivalent) from one machine to another, and it would look and feel just like... home.  The reality often falls somewhat short, and on Windows (in large part because of the registry) it's not even close.  Likewise, you ought to be able to go back to a near-factory install by removing all user-accessible folders.  Again, this is not quite true in practice anywhere, and as you might guess by the number of aftermarket system cleaner utilities, it's particularly not true of Windows.

On IPad, it takes 25Gb of stuff and unknown amount of money to start programming, the language of choice is not even Java, but something completely obscure, and you can't just run a program on a phone anyway - signing needed. The silver lining is that you can relatively easily use other languages instead of their mutated C++ clone.

Isn't it just Objective-C?  That's no more obscure than C#, and actually dates back to the 80s.  It's also not technically Apple's... although they are one of the more prolific users.  C++ may be common, but it doesn't always get tons of love from developers -- many of whom either stick to C, or move on to C#, Java, or Obj-C.

I could rant on about how truly awful the MSI database schema is, but I'm afraid it would serve no purpose other than to make me angry.

If you would like to vent for a while about how horrible the registry and MSI are, I will gladly hum Amazing Grace as a backdrop for you.  Both fine examples of how NOT to architect systems.

[Howardlong]

I like this thread!

Two rants for the pot..

1) Provisioning an IOS app and a device must be one of the most painful, unproductive processes ever. Oh, wait, until you try to develop for the Playbook (remember that?)

2) Microsoft Visual Studio 2012 C programs use startup code that call Windows APis that don't exist in XP by default. As you can imagine, when VS2012 was released, about 1/3 of PCs were still running XP. It took 3 months for MS to release an update. Meantime, we all went back to using VS2010.

But yes, in general, these days many programs and systems install only half finished, ie, there is a lengthy configuration and setup process to go through after install, much of which is trial and error and often error prone.

[amyk]

2) Microsoft Visual Studio 2012 C programs use startup code that call Windows APis that don't exist in XP by default. As you can imagine, when VS2012 was released, about 1/3 of PCs were still running XP. It took 3 months for MS to release an update. Meantime, we all went back to using VS2010.

Link to MSVCRT.DLL: http://stackoverflow.com/questions/10166412/how-to-link-against-msvcrt-dll-instead-of-msvcr100-dll-in-vc-10-0

Makes small, self-contained executables that will work basically from Win95 to Win8 (if you take care not to use the newer APIs.)

[free_electron]

i too have long wondered about the convoluted install systems ( on any computer )

a program install should be as simple as : create a folder . throw all required files in there , make a shortcut that points to the startup object in that folder.
in essence the program 'lives' in that folder. anything it needs to persist gets written to files in its 'home'. user data is written to userland folders.

want to move a program, and its settings from machine a to b ?  copy the folder over to other machine and run. that's it.
i am even willing to give up disk space so we can do away with shared libraries et al. disk space and memory are cheap.

but i guess the anti piracy guys would be up in arms if it were that easy to move a program from one machine to another...

that being said. i wonder if there is a tool that can actually analyse an installed program , collect all required files and registry settings so you can move a program from machine a to b. here is an instance where this could be usefull : i have a scope running win2000 with a preinstalled program. standalone installers are not avaialble. only a recovery disk that reimages the drive. i want to pick off the program. wipe the drive ,install xp , redeploy.

so this tool would have to analyse all the calls that are being made during the program run to load dll's , vxd's, whatever , monitor all registry keys being accessed (read and write ) and collect everything needed.

that would be a cool tool to have.

[krivx]

ProcMon can monitor all file and registry access http://technet.microsoft.com/en-ie/sysinternals/bb896645.aspx I don't know if there is an automated way to log the changes made just by installing a program though.

[aroby]

I agree completely.  It has a lot to do with the Windows use of the registry.  But why, oh why, did the Windows architects decide that so many things critical to the functioning of every program should all be piled together into a single monsterous database, with virtually no checkpointing, no transaction support, no segmentation, virtually no protection, no ability to backup/restore along with the file system, etc.?  Every Microsoft programming technology since COM has made the registry a crucial piece of the puzzle.  The use of the registry has made it difficult or impossible to have a nontrivial program "just work" if you copy the program to a directory and run it.

The Windows architects never designed the registry to handle everything that is now piled into it.  It was supposed to be central place for system and per-user configuration information.  As you point out, it has no protection of any sort, but then again its use cases didn't require them.  And it requires a context switch (I assume that is still the case) to access it.  Problem was when the COM guys and numerous 3rd party developers started to pile on to it and tied it up in a byzantine mess.  COM in particular should have had a separate registration database.

The opportunities for ranting against Microsoft become even more numerous when you look at the solution they recommend for the problem of getting files and registry entries onto a machine.  They came up with the Microsoft Installer (MSI) technology, which uses a convoluted relational database.  The database has 100 different predefined tables in its schema, with optional additional custom tables.  All for the simple task of copying files and registry entries to a machine!

And don't get me started about the evils of the MSI patching technology!

Maybe you've never had the pleasure of working with SMF on IBM mainframes!  MSI is a joy compared to that.

Anthony

[rdl]

A lot of stuff I use runs without actually being installed. SumatraPDF, utorrent, AviDeMux, Notepad++, and lots more. I think Handbrake and VLC will run as portables also. Many programs that think they need to be installed can have their folder copied and moved to another computer without being re-installed, even those that write some settings to the registry.

The registry is a bad idea, nothing should use it but Windows itself. Other applications should save settings in xml files within the program folder, though this can't be done if that folder is in Program Files.

[AG6QR]

The opportunities for ranting against Microsoft become even more numerous when you look at the solution they recommend for the problem of getting files and registry entries onto a machine.  They came up with the Microsoft Installer (MSI) technology, which uses a convoluted relational database.  The database has 100 different predefined tables in its schema, with optional additional custom tables.  All for the simple task of copying files and registry entries to a machine!

And don't get me started about the evils of the MSI patching technology!

Maybe you've never had the pleasure of working with SMF on IBM mainframes!  MSI is a joy compared to that.

No, I haven't dealt with SMF.  However, in the distant past, I have dealt with IBM mainframes, and the joys of JCL on MVS/TSO.  I've allocated partitioned data sets, compressed them when they fill up, etc.  It would be difficult to argue that Microsoft's MSI is worse than the worst of IBM's mainframe technologies, because IBM has released some stinkers.  But what's awful is that MSI actually copies some of the worst of IBM's practices.  For example, when an error happens during installation, MSI throws up a four-digit error code.  When you see one of these, you have to manually go to a help file (or look on line) to convert the code to a human readable error message.  Now, if there's one thing computers are better at than people are, it's looking up numbers in tables.  Back in the early days of the IBM punched card systems, perhaps it made sense to use numeric error codes that referred to a written message printed in a reference manual, because the error messages would take too much valuable system storage if you stored them on the computer.  But these days, the computer should look up the error message and present it in human-readable format.

I hope nobody ever looks at anything I've been involved with and says, "Sure, it was pretty bad, but one time, IBM managed to release something that was worse".

Arrgh, this discussion isn't doing anything good for my blood pressure.

[Sigmoid]

Just dug up a shoeboxfull of a Windows 98 computer - it takes longer to boot up than both a Win7 PC and an Android tablet.

That era was the undebated low of desktop computing. The pure shittiness of both hardware and software of that time is unrivalled by anything before or since.

What's with the more recent fashion of putting config and data files into some obscure location in a user profile, instead of keeping them in the program's directory?

Multi-user systems. It's not recent, UNIX software have been doing that back when you just got your first C64.

Programming is also a thing that withers away, especially in the mobile market.
On WindowsCE, PocketPC, you could just write a program with whatever tools, copy it over, run it, and it works.

I wouldn't be so pessimistic. Also, I would be wary of mentioning Windows CE in any favorable context. (See my comment above about the uncanny valley of computing shittiness.)

On Android, there is 500Mb bundle of software of all kinds and shapes that produce a program, with little to no other options. You can only program in some sort of Java, in a rather clumsy fashion. Sure, you can use GCC and C, but then be limited to console applications.

It's called a toolchain and a library. It's been a fact of life since UNIX times, only obscured from you by being bundled with the OS or in other ways.

On IPad, it takes 25Gb of stuff and unknown amount of money to start programming, the language of choice is not even Java, but something completely obscure, and you can't just run a program on a phone anyway - signing needed. The silver lining is that you can relatively easily use other languages instead of their mutated C++ clone.

The unknown amount of money is $99 a year. You can see signing as part of the build process, nothing esoteric about it.
As for Objective C, it actually predated C++, and follows an entirely separate school of OO. Basically, on one hand you have C++, JAVA and C#, and the whole bush of programming languages that grew out of C++. On the other, you have ObjC. It's a strange but likeable language. I like calling it a living fossil.

Just why make it so difficult?
Your platforms is nothing without developers!

In certain ways, it never has been easier.

[amyk]

i wonder if there is a tool that can actually analyse an installed program , collect all required files and registry settings so you can move a program from machine a to b. here is an instance where this could be usefull : i have a scope running win2000 with a preinstalled program. standalone installers are not avaialble. only a recovery disk that reimages the drive. i want to pick off the program. wipe the drive ,install xp , redeploy.

so this tool would have to analyse all the calls that are being made during the program run to load dll's , vxd's, whatever , monitor all registry keys being accessed (read and write ) and collect everything needed.

that would be a cool tool to have.

Plenty of those around; just look for "portable app creators" and "install monitors".

[SirNick]

a program install should be as simple as : create a folder . throw all required files in there , make a shortcut that points to the startup object in that folder.

From what I remember, a lot of the trouble comes from dealing with the library management implementation in Windows.  This is also why the disk requirements of any installed Windows system continually grow, and grow, and grow, and grow...  Basically, you can't ever throw away a DLL.  Something might need it someday.  So every time you install a service pack or patch, your apps keep running .... but you collect an awful lot of cruft, and it becomes a horribly complicated mess of app registrations and versioned libraries.

Beg pardon if I got anything wrong there.  I looked at installation frameworks and WinSxS details a few times and decided, "Nope."  I would much rather deal with Linux dependencies with Gentoo's portage.  (Which is not always fun either.)

i am even willing to give up disk space so we can do away with shared libraries et al. disk space and memory are cheap.

Not such a great solution either.  It leads to a lot of wheel-reinventing, a ton of wasted space (imagine if every DLL had to include the entire C runtime!), and it would make patching security holes a real nightmare.  How many times has OpenSSL been in the news recently?  Now imagine if every app that used encryption had to be recompiled and redistributed to fix those issues....  As it is, the OpenSSL guys can provide a patch, the library can be replaced, and all your dependent apps are now secure.

(Unless they require out-of-date versions, and can't use the new API, which is sometimes the case.  Can't save 'em all.)

[rollatorwieltje]

i too have long wondered about the convoluted install systems ( on any computer )

a program install should be as simple as : create a folder . throw all required files in there , make a shortcut that points to the startup object in that folder.
in essence the program 'lives' in that folder. anything it needs to persist gets written to files in its 'home'. user data is written to userland folders.

want to move a program, and its settings from machine a to b ?  copy the folder over to other machine and run. that's it.

That's basically how most applications work on OSX, it's called an appbundle. Unfortunately OSX doesn't really enforce the use of appbundles, so some applications still insist on having an installer. Which is horrible, because OSX doesn't have something like Windows' "Installed applications" or a package manager so you'll have to keep the original installer to uninstall something.