Write an App/Program that lasts a lifetime
That sounds like fiction, doesn't it? In todays age of disposable apps and ever changing technology, how can an app / program last a lifetime, even the hardware changes so often that it would be next to impossible to keep the app running. Well, here's a quick journey and comparisons of some apps.
There was a time when devs actually knew each and every of the menmonic available in the Z80/8085 CPU execution set. Motorolla took a risk (pun intended) and introduced the RISC (Reduced Instruction Set Computer) this had a limited number of mmemonics and performed practically all of the tasks that could be done. [You can read up on how it works by googling it]
In addition to this, Assembly was not easy for all, and it was not very forgiving, you could crash the system easier by simply using a wrong op code. There were a whole sleuth of languages, like how there is an overload of .js frameworks all doing the same thing but slightly differently. However the only thing that was different was that instead of competing for the same solution, they had a niche and area to work on. Not every tried to make the next Instagram, facebook or Uber, there was dBase that worked with Databases and programming, C and Basic for writing applications, Lotus 1-2-3 for Spreadsheeting, Wordstar for writing letters and documents. (I can vaguely remember the dot commands used to specify the settings for that page and no WYSIWYG) you had to print to a dot matrix printer to know what you got. With GUI systems, like Windows 3.x, OS/2 came other options like Visual Basic, Visual FoxPro, Delphi, etc.
For the more serious programmers, there were the C variants like TurboC, (I still recollect most of the applications always started with detecting the driver and then setting the display with those settings) once the screen mode was set to graphics, you could sraw on the screen using lines, circles, etc. You could use offscreen screenbuffers, draw and then swap them to active to have smooth animation/changes. This then gave way to Visual C++ (I still have the original VC++ 1.0 CD) with MFC (Microsoft Foundation Classes) while Borland had their version of C++ libraries with OWL (Object Windows Library).
There was a whole set of offering, the buzzwords in the 90's was RAD (Rapid Application Development) and the paradigm was drag drop and flowchart based and HyperCard type applications. There were a whole lot of companies like Aldus (PageMaker), Macromedia (Director, Authorware, etc) many of which did not last or were bought out or merged with other companies.
Depending on the part of the world you were in, software was treated differently, I recollect a magzine that was printed in Italy that came with a cassette (like you get CD's and DVD's), side A had all Spectrum Games and side B had games for the Commodore 64. The printed magazine had description about the games. If you were a subscriber to some of the Scandinavian hackers groups or knew someone that knew someone, you could get cassettes with games that had specific loaders, these loaders boasted how this game was cracked before it would continue to load the game. The point is that at that time, unless you were a large organisation, you would pay a hefty sum for the hardware, the person installing the hardware would quote (note this very interesting point) that the computer would come pre-loaded with a choice of softwares. It was considered the norm and no one realy bothered about the legitimacy of the software (OS). Though companies would cribbed about how Accouting software was expensive and so was employing some operators to run the systems. Things began to change, by 2000 the push and drive to have legal software was strong (I have wored closely with Microsoft in one of the larger organisation I worked in, to have EA's in palce to have proper licenses for each and every software that was in use). Prior to the licensing, one could request for each and every software they fancied or simply copy it from the other via floppy disks (USB's and External Drives came a lot later).
If you want to run any of the software from that era, you could, some of it is available on Abondanware sites, some require emulators and or a 16/32 bit system like windows 3.x or 95/98.
1. My basic environment had changed, I used Windows and now my main machine is an iMac
2. The software that used to be on Floppies, etc were archived onto CD's
From some of the 3rd party CD's I found, used to have a Windows and a Mac partition, but I could not run any of the Mac apps as they were PowerPC applications, they could work on Tiger or Leopard using Rosetta, but since Snow Leopard, Apple had closed that door bidding goodbye to the old software.
My development stuff was Windows, using a mix of Languages, technologies, mainly VB (at that time I recollect having a directory of utils with vbrun100.dll, vbrun200.dll) after VB4, that came in both 16-bit and 32-bit, these were kind of obsolete and as most of the apps are now VB6 compliant, the runtime was available with Windows 7. So I gave it a spin and found that most of my apps *GASP* worked, the font size looked ultra-small and horrid to read, but they worked.
On a comparitive note, some of the iOS apps that I had developed with SDK 3.0 (which are still on the app store) work even on the latest iOS 8.x (but for one little boo boo from Apple, which could illustrate why using non-documented functionality is bad) Apple used to have some sounds as part of the API, so you could use the system resource sound for a *clink* type sound, they removed it and now when the app tries to load that, it crashes!!
The problem starts when you try to open these in the Editors for updation. They go all over the place (which is strange).
The same is true for the Mobile Apps (iOS), things have changed (I use a generic term things, as it includes UI, interactivity, etc) and where users literally buy apps by looking at the screenshots, the glossier the screenshot or icon, the better chance the app has of making a sale. In that sense, you would not like using the app and be unhappy than happy or productive using it.
Windows Apps on the other had are a different breed, they are the underdog, the ones that run your systems in the background but are least appreciated. One reason is the bad techniques used by many rookie developers, the TAB indexes are never set, no UI Guidelines are followed, the use of colour is horrendous. The worst sin of all, the screen is crammed with tonnes of text boxes and buttons, instanty giving a brain freeze to the user, screaming COMPLICATED!!
The other funny thing was that while the VB executables worked (unless they relied on some OCX that are no longer available or do not work with Windows 7) the backend was a bit of alet down, with so many database technologies and drivers, you cannot open a simple Access 97 type mdb database using Access 2013 or the database access methods. However you can create a ODBC DSN and access the entire database and data from Excel or any other application that allows ODBC data sources. Even from VB, if you use ADODB, you can access the database. This was a let down, however I was happy that my app was created with the fact that users could mess (read as delete the database file) so it would not crash but simply not perform any db routines.
If this was interesting, look for the next one, where I discuss some of the finer points that I feel are still applicable, relevant and still not utilised as commonly after 15 years or so.
Note: The Images are copyright of the sites that they are from.
Running Older software
The first enabler that some developers have adopted is to use emulators. These emulate the software environments of systems that fdo not work anymore. Like VirualBox, VMWare or Parallels or if you are a *nix fan, qemu and the like. The only problem with this approach is that you run an expensive overhead of an entire OS on your machine, just to run a particular app. Like at a particular large organisation of teaching and learning, they had to run windows 98 or an earlier version just because their enterprise help desk system would work *wait for it and shudder* only on an older version of IE and fail on other browsers. For other non enterprise systems, there are emulators that emulate the older systems, like the ZX Spectrum, Commodore64, Atari, Amiga, etc. These are more or less hobby applications as these systems do not run any critical systems anymore.CPU Architecture Changes
The one thing that has changed the way software works is the CPU architecture, I started my journey with Z80 (for those that do not know what this is, it is the Zilog 80 CPU, which was *the* revolutionary* chip at the time before the 8085 which was similar in terms of OPcode Mnemonics and registers, etc. Different systems used different CPUs, the PC revolution started with the PowerPC and the Intel x86 chips. Apple machines were PowerPC where as the Wintel and *nix boxes ran on the x86 CPUs. Then Apple changed their systems to Intel and the rest literally is history, this led to the largest adoption of Macs then ever. There were a whole lot of other CPU's like MIPS, ARM, etc ultimately today the ones that many compile for are Intel or ARM (used in majority of the Mobile devices). This is not about the CPUs, but the fact that each CPU has different OPCodes and the code is different, so you cannot simply run the compiled code for one on the other. Similar to how you cannot run a Windows ecxecutable on a Mac or an ELF (linux executable) on Windows or a Mac.There was a time when devs actually knew each and every of the menmonic available in the Z80/8085 CPU execution set. Motorolla took a risk (pun intended) and introduced the RISC (Reduced Instruction Set Computer) this had a limited number of mmemonics and performed practically all of the tasks that could be done. [You can read up on how it works by googling it]
Computing Languages
There were more assembly developers in the 80's and 90's than there are today, it makes sense as assembly is good for working with the lower levels of the machine/CPU and screen, so you could write text to the screen directly by modifying a memory location. With GUI environments, the entire system became encapsulaed, with drivers taking care of screen updates, so you had to talk to the screen driver to write to the screen. You could also have fonts as compared to the earlier fixed terminals that could only have 80x24 type screens, so you simply set the screen location with the ASCII character and you could see that character on screen. Many of the older games relied on this method, they would simply check the character at position x, y and if that was an enemeny or wall, you had either crashed or been attacked.In addition to this, Assembly was not easy for all, and it was not very forgiving, you could crash the system easier by simply using a wrong op code. There were a whole sleuth of languages, like how there is an overload of .js frameworks all doing the same thing but slightly differently. However the only thing that was different was that instead of competing for the same solution, they had a niche and area to work on. Not every tried to make the next Instagram, facebook or Uber, there was dBase that worked with Databases and programming, C and Basic for writing applications, Lotus 1-2-3 for Spreadsheeting, Wordstar for writing letters and documents. (I can vaguely remember the dot commands used to specify the settings for that page and no WYSIWYG) you had to print to a dot matrix printer to know what you got. With GUI systems, like Windows 3.x, OS/2 came other options like Visual Basic, Visual FoxPro, Delphi, etc.
For the more serious programmers, there were the C variants like TurboC, (I still recollect most of the applications always started with detecting the driver and then setting the display with those settings) once the screen mode was set to graphics, you could sraw on the screen using lines, circles, etc. You could use offscreen screenbuffers, draw and then swap them to active to have smooth animation/changes. This then gave way to Visual C++ (I still have the original VC++ 1.0 CD) with MFC (Microsoft Foundation Classes) while Borland had their version of C++ libraries with OWL (Object Windows Library).
There was a whole set of offering, the buzzwords in the 90's was RAD (Rapid Application Development) and the paradigm was drag drop and flowchart based and HyperCard type applications. There were a whole lot of companies like Aldus (PageMaker), Macromedia (Director, Authorware, etc) many of which did not last or were bought out or merged with other companies.
Applications
The last couple of decades saw a lot of changes to the hardware, the software, the way we purchase and consume hardware and software. In the 80's special rooms were build to house computers, the air-conditioned, dust free offices were for computers and being a computer operator was a special designation in the organisation, the computer programmer was nothing short of a rock-star.Depending on the part of the world you were in, software was treated differently, I recollect a magzine that was printed in Italy that came with a cassette (like you get CD's and DVD's), side A had all Spectrum Games and side B had games for the Commodore 64. The printed magazine had description about the games. If you were a subscriber to some of the Scandinavian hackers groups or knew someone that knew someone, you could get cassettes with games that had specific loaders, these loaders boasted how this game was cracked before it would continue to load the game. The point is that at that time, unless you were a large organisation, you would pay a hefty sum for the hardware, the person installing the hardware would quote (note this very interesting point) that the computer would come pre-loaded with a choice of softwares. It was considered the norm and no one realy bothered about the legitimacy of the software (OS). Though companies would cribbed about how Accouting software was expensive and so was employing some operators to run the systems. Things began to change, by 2000 the push and drive to have legal software was strong (I have wored closely with Microsoft in one of the larger organisation I worked in, to have EA's in palce to have proper licenses for each and every software that was in use). Prior to the licensing, one could request for each and every software they fancied or simply copy it from the other via floppy disks (USB's and External Drives came a lot later).
If you want to run any of the software from that era, you could, some of it is available on Abondanware sites, some require emulators and or a 16/32 bit system like windows 3.x or 95/98.
App Longevity
Just recently I was cleaning up and I came across a very interesting collection of stuff I had. There were a couple of things that had changed personally for me,1. My basic environment had changed, I used Windows and now my main machine is an iMac
2. The software that used to be on Floppies, etc were archived onto CD's
From some of the 3rd party CD's I found, used to have a Windows and a Mac partition, but I could not run any of the Mac apps as they were PowerPC applications, they could work on Tiger or Leopard using Rosetta, but since Snow Leopard, Apple had closed that door bidding goodbye to the old software.
My development stuff was Windows, using a mix of Languages, technologies, mainly VB (at that time I recollect having a directory of utils with vbrun100.dll, vbrun200.dll) after VB4, that came in both 16-bit and 32-bit, these were kind of obsolete and as most of the apps are now VB6 compliant, the runtime was available with Windows 7. So I gave it a spin and found that most of my apps *GASP* worked, the font size looked ultra-small and horrid to read, but they worked.
On a comparitive note, some of the iOS apps that I had developed with SDK 3.0 (which are still on the app store) work even on the latest iOS 8.x (but for one little boo boo from Apple, which could illustrate why using non-documented functionality is bad) Apple used to have some sounds as part of the API, so you could use the system resource sound for a *clink* type sound, they removed it and now when the app tries to load that, it crashes!!
The problem starts when you try to open these in the Editors for updation. They go all over the place (which is strange).
The Verdict
The programs on the Apple Mac systems have moved on and show little or no love for older applications, this is fine and in many ways good, since the Mac UI has changed a lot over the time and it could be difficult working with those apps (if they would function)The same is true for the Mobile Apps (iOS), things have changed (I use a generic term things, as it includes UI, interactivity, etc) and where users literally buy apps by looking at the screenshots, the glossier the screenshot or icon, the better chance the app has of making a sale. In that sense, you would not like using the app and be unhappy than happy or productive using it.
Windows Apps on the other had are a different breed, they are the underdog, the ones that run your systems in the background but are least appreciated. One reason is the bad techniques used by many rookie developers, the TAB indexes are never set, no UI Guidelines are followed, the use of colour is horrendous. The worst sin of all, the screen is crammed with tonnes of text boxes and buttons, instanty giving a brain freeze to the user, screaming COMPLICATED!!
The other funny thing was that while the VB executables worked (unless they relied on some OCX that are no longer available or do not work with Windows 7) the backend was a bit of alet down, with so many database technologies and drivers, you cannot open a simple Access 97 type mdb database using Access 2013 or the database access methods. However you can create a ODBC DSN and access the entire database and data from Excel or any other application that allows ODBC data sources. Even from VB, if you use ADODB, you can access the database. This was a let down, however I was happy that my app was created with the fact that users could mess (read as delete the database file) so it would not crash but simply not perform any db routines.
Wait a Minute - I did not learn HOW TO write
You might be right upto a point that you did not learn to write an app that can outlive the test of time, however the idea of the article, which it does make clear at a couple of places is dependent on a couple of things namely the hardware, the software and the OS technology. You can also read up Portability Techniques (mainly if you are more of the Computer Scientist type developer and can survive reading a technical article). Your dotNet apps can run on Linux and Mac as well as Windows using the Mono Framework but only if it uses the API and functionality offered by the current version of Mono. The VB6 executables worked because of the combination of the VB6 intermediate code in the executable. Personally I have a strong opinion when it comes to Java and it has survived the test of time and spawned so many more monstorities and attrocities, let's not get started on that one. The C++ or C applications work fine as long at the underlying OS or the CPU architecture is not changed. With every update, libraries have deprecated code and functionality so if the function your app relies on is totally unavailable, then the app will crash and not work.If this was interesting, look for the next one, where I discuss some of the finer points that I feel are still applicable, relevant and still not utilised as commonly after 15 years or so.
Note: The Images are copyright of the sites that they are from.
Comments
Post a Comment