Programming in the 21st century


I started writing microprocessor programs in 'hand crafted' assembly language. This was the early 1980's and the processor of choice was the ZILOG Z80. The method of programming was painstaking. Write the code as mnemonics in an exercise book. Using (very important!) a pencil. Looking up the hexadecimal value in the Z80 manual and writing it along side the mnemonics. When I had finished my section of code, I would then type it in to a file on an Hewlett Packard desktop development computer. This machine cost serious money and was owned by my employer at the time. I could only get to the machine in my lunch hour when the 'user' was on lunch. This machine had an EPROM programmer which could take the file and program an EPROM from it. It took over a month to write and debug a simple program to make the ZX81 do Radio Teletype with a serial chip. The Intel 8251 was put on a plug-on prototype board and connected to the ZX81 via the back connector. It worked eventually!


Later on I used a CP/M machine to write programs both in 8080 (cpu compatible) assembler and BASIC. These BASIC programs were written on a CP/M Personal computer. In the mid-80's, the company I was working for got an early IBM PC XT. The processor was 'different'! Similar in some ways but quite different in lots of others. It was called a '16 bit' processor. But it 'talked' to the outside world, 8 bits at a time. Suddenly I had to understand 'segmented' addressing. This was to hold back a lot of people as it was confusing and limiting in address space. When we eventually created very large arrays in BASIC, the wheels would quite often fall off. Bringing down the DOS system. Thank you Intel for providing a 'flat 32 bit' model and a 4GB address space later on!


During this period of years, I used both Quick Basic and Professional BASIC with the Microsoft Assembler or Quick C to build some very complex programs. Communications was my forte. Using the RS232 ports of the IBM PC or compatible, I wrote a great many programs. BASIC stands for 'Beginner's All-purpose Symbolic Instruction Code'.


{- spurious comment -}

Extracted from 'Code Project' Newsletter

Survey period: 31 May 2010 to 7 June 2010

For our C++, VB and .NET developers: Are you still on your tried-and-true version, or have you moved onwards and upwards?

Option

Votes

%

Visual Studio 2010

599

39.96

Visual Studio 2008

1016

67.78

Visual Studio 2005

447

29.82

Visual Studio .NET 2003

130

8.67

Visual Studio .NET

17

1.13

Visual Studio 6

235

15.68

Visual Studio 97

5

0.33

Developer Studio 4

5

0.33

I do not use Visual Studio and never have

6

0.40

I have used, but no longer use Visual Studio. I have moved on.

22

1.47

Responses

1499


Respondents were allowed to choose more than one answer; totals may not add up to 100%

I take heart from the 'sizeable' chunk of programmers that responded with Visual Studio 6 and 97. JB

{---}


Having lost interest in VB.NET, I am now using DEV C++ with the GNU C++ (MingW) compiler. Both are 'free' and freely available. They are very good at producing blazing fast applications with little footprint. It mocks the humongous .NET run time and produces small executables that transfer over the Internet in a flash. If I really wanted to, I could write new or move my old programs to VB style programs in Gambas and run them on Linux. But as yet there is no great market for them yet. I was hoping the 'backlash' to VB.NET would prompt a VB7 but that didn't happen. Similarly I was disappointed to see that KYLIX has 'disappeared'. That was going to provide cross-platform applications, written in DELPHI/PASCAL, to run on Linux systems. The irony of DEV C++ is that the IDE is written in DELPHI! The huge plus in my book is that it doesn't need a huge runtime to perform like Eclipse needs the JAVA runtime to work.


For BASIC compilation, I have recently discovered a vastly improved Free BASIC Compiler. FBC is cross-platform. That is the source code can be compiled to run on both Windows and Linux. It could also be adapted to provide object code for other systems with other cpu types. I got an email from the son of my friend of over thirty years.. His problem was that his engineering program that had worked for the last 20 years, now did not work under Windows 7. It was written in GWBasic and "tokenized". That is saved in binary format. The first version of this program was written in the latter half of the 1980's. The program when de-tokenized, does compile under VBDOS and works. But not under Windows XP/Vista/7. As it sets the SCREEN to a full screen graphics mode. Windows 7 and Vista don't like this. Sad but true. The program is quite long and involved so it was not really possible in the time available to re-work the program.


I looked in my BASIC area of my downloads folders and found an old (4 years, that is OLD!) version of FreeBASIC. This compiled it but with a large number of errors. So I downloaded the latest version. This produced a program that works 100% under XP/Vista/7 and Linux, with it's own screen window. I am now going to look into using FreeBASIC to compile some of my veteran programs... You can find FreeBASIC at http://www.freebasic.net/ and on Sourceforge.


In this country (South Africa), we have quite a few users of PC's still running on Windows 98. (2009) Even some on Windows 95. So I was heartened to hear that VB.NET programs could be run on Windows 98. Whoops! If you install the .NET framework as well. If he doesn't have a big hard disk or plenty of memory, you could have a problem. With the addition of WxWidgets, you can write cross platform programs that will work on Windows 98, ME, NT, 2000 or Mac or Linux with either GTK+ or X window system. They will also 'look' the same on these platforms. Not quite as 'pretty' as Microsoft's themes and styles but good enough to use.


Previous Microsoft perversions to BASIC, (sorry that should have been, 'versions', but my foot slipped), have been a 'simple' upgrade to the editor. It wasn't an IDE in 'my day'. It became a fair editor/compiler/run environment when it became QuickBASIC. Producing moderate sized executables at fair speed with nice looking user interfaces became second nature to me. Any special functionality would be provided by a C or assembler module, linked in as either a 'Quick library' or into the final executable from a 'library'. The library was a collection of 'proven' object code modules written in C or assembler.


When Windows arrived at version 3, things started to change. The user interface - of course - became graphical. The code remained pretty much the same with the addition of the Windows API helping the program perform all the usual functions. The runtime as before became larger, a dynamic link library from a smaller static linked-in library. It was still quite small, around 265k bytes or so. The 'event driven' model worked well to adjust the mind set of the 'old programmer'. The 'object orientated' model of later versions eased the programmer into the new world of 32 bit computing and allowed him to generate quite presentable and saleable programs. Remember that in those days, memory was an expensive commodity. So small size programs were not just just desirable but mandatory. Later VB6 programs had to be installed from CD because the run-time alone would not fit onto a 3.5” disk. Nor for that matter the Microsoft Installer, which would eat up available space like a voracious child. Earlier VB programs did not require “installation” and would run from where you copied them. Multi-user was not in our vocabulary then. Adding an icon for the application was a user function. He or she would decide if your program got a teddy bear as the icon, if she liked it, or another more violent icon if she didn't.


Over the last ten years or so, the script program has risen up to replace the old 'batch file'. These scripts make life easy automating the system and running utilities on your PC. As these are generally text files they can be easily generated in Notepad and interpreted by the run-time dynamic link library. They don't allow access to the Windows API directly but do allow use of 'system objects' with a huge number of functions. Some of these scripts are directly interchangeable with those of a web page. Unfortunately most are now 'banned' from running in a web browser as they could both be a 'sexy interface' or a 'viral scourge'. A large number of ISP's will remove scripts from emails that used to make emails fancier. Or if you work out a great script and send it to a friend, it will be stripped off and destroyed before he gets it. Scripts can be written in different languages such as VBscript, Javascript or even Perl.


Microsoft admits quite freely that the scripting interface is not going to be changed anytime soon. They really don't need another large block of user/programmers moving away from the Microsoft model. They have already lost the scripters who used to write the web server scripts as PHP has replaced the ASP scripts for server-side scripts. And of course the ones who couldn't cope with ASP.NET. Microsoft is now trying to woo them all back with the new “freebie”, 'Expression Web'. If you remember FrontPage this is its replacement.


Once upon a time, or last century, you would pay for the compiler etc. Nowadays it is in their best interest to have the programmer go their way, so the compilers and IDE's have 'free' or 'express” versions. So you can get VB.NET, C# and all the others as 'express' versions either as a download or as a give-away magazine CD. For the younger, more agile programmers its quite alright to go this route. Borland programming products used to be this 'free' but now Borland have given up this end of the business. The C++ and Pascal based compilers are no longer free, though there is an Open Source Pascal. The licence also used to stop you from making money from the program you had written in your spare time. Now its Microsoft's turn. Woe betide you if you write a program that makes C# express work better or more efficiently. Microsoft's lawyers will trample all over you. Microsoft have always been sensible about their software market. They prefer to attack at the bottom by giving the software away to students or 'learners'. Or at the very least making it a fraction of the cost of the shop sold product. This gets the young into the use of their software. So when they go to industry, they insist on the Microsoft product in their working life. So now we have a 'home and student' version of Office. Its also supposed to be sold only to bona fide educational establishments or persons.


Databased

Microsoft gave us, the PC world, “open database connectivity”, clobbered all the old expensive databases like Dbase, Btrieve and the others. They also gave us Access for our databases, old and new. Now they are covering this up from the rest of the industry. They would prefer it if you used a 'native' interface or a .Net based solution to connect to their SQL server or data engine. Access and DAO hasn't gone .NET yet and probably won't for a while. They are also quite happy to give you 'free'/'express' versions of SQL server to pull you away from looking at an ODBC solution with say MySQL server. So if you are writing a new database solution, Access still represents an easy, low cost solution. Unfortunately if you want a multi-user interface with both application and web interfaces, it just isn't going to be that easy. What a few years ago, I would have written in VB6, you must now write in .NET. The web based interface will have to be written in ASP.NET. The in-house database can still be created in Access but your upgrade path to an SQL solution is strewn with obstacles. Why not start by posting all your spare cash to Microsoft? After all the SQL user licences are doing this right now.


Years ago, I would have prototyped a hardware solution with a small high cost item. Then produced a manufacturing prototype or several for pre-production costings. Finally giving the client an accurate costing for production based on the costs involved. Software is similar but not the same. An in-house database for a small company can “grow” into a multi-user, multi-function database. The growth path would be lengthy and relatively slow over a year or two. With the old Access way of doing things it could be easily “beaten into shape” and migrated into a reasonable cost SQL server based solution. Nowadays, you (the client) are expected to pay a small fortune up-front and another small fortune in licence fees and another in support costs as the developer beats it into shape or how you wanted it in the first place.


Interestingly Open Office interfaces easily with a MySQL server or database with just about the same 'ease of use' as an Excel to Access solution. Or if you are like me (cheap), you can “export” your Access database tables to MySQL over an ODBC connection. Move the queries from Access SQL to MySQL stored procedures and quickly remove the “sharp edges” with a little thought. Resulting in a very low cost database solution for Intranet and Internet.


The writing is on the wall (economic downturn 2008) .

When faced with high costs of development, the small to medium sized company will not pursue the project. Preferring to shelve it or put it on the back burner. It fits in with their scheme of adding more employees to solve the 'time equation'. Or they will find another way. Perhaps using a 'standard' software package in a convoluted but workable solution.


John K. Brock

This document was written and formatted using OpenOffice Writer and saved as html. 2010-12-20