Dr. Jerry Pournelle

Email Me


Why not subscribe now?

Chaos Manor Subscribe Now



Useful Link(s)...

JerryPournelle.com


Hosting by
  Bluehost


Powered by Apache

Computing At Chaos Manor:
The Mailbag

Mailbag for May 21, 2007
Jerry Pournelle jerryp@jerrypournelle.com
www.jerrypournelle.com
Copyright 2007 Jerry E. Pournelle, Ph.D.

May 21, 2007

We continue the discussion of VB 6 support, but first a report from Peter Glaskowsky on Vista 32. It was actually sent as part of a discussion of 64-bit Vista, which I do not recommend for production work.

I just installed Vista and Office 2007 on my Motion LE1600 Tablet PC, which I use to take notes at meetings, conferences, etc.

It's kinda slow (because the machine itself is slow), and the Intel integrated graphics doesn't support the advanced Aero GUI features, but it's okay.

. png

As for me, I continue to have problems getting Vista to network properly, and I have yet to get Vista and Outlook 2007 to connect to my ISP. The problem appears to be some kind of firewall, because I can ping my ISP and get a return; but when Outlook through Vista tries to connect, I get a message that the connection is impossible. I will work on this when I get back from my trip to the DC area.


On Linux and Microsoft and Patents

Subject: Linux and Microsoft patent infringements.

I tend to think this is all FUD.

For one thing the details you gave are kind of sketchy. From what you wrote most of the patent infringements in Linux are not in Linux at all. Yes any patent infringements in the Kernel could be considered patent infringements in Linux but Open Office isn't part of Linux. In fact I would bet most Open Office users are running Windows. Open Office has a non-free version called Star Office and that is sold by Sun. Any patents infringements in Open Office should be referred right to Sun.

Also Linux doesn't have a GUI. There are GUIs that run under Linux like KDE, Gnome, WindowMaker, and a number of others that are more or less popular. Which GUI infringes? If one falls then another will take it's place.

So most of the patents that Microsoft claim "infringes" in Linux are not part of Linux at all. They are applications that run under Linux and it the case of OpenOffice under Windows.

As to a fight between IBM and Microsoft I just don't think that Microsoft is that stupid. IBM has more patents than Microsoft and odds are very high that Microsoft is infringing on more IBM patents than IBM or Linux is infringing on Microsoft's. Right after never fight a land war in Asia is the rule. Never get into a patent fight with IBM.

Finally Microsoft is acting in bad faith at this point. If there are patent problems why tell the community exactly what they are so that they can stop infringing on them? The only reason not to is if Microsoft isn't trying to use the patents to protect their intellectual property rights but are using them to destroy competition. Since they are a convicted monopoly such behavior seems very anti-trust to me.

JJ

I have a commentary on this in the column. I don't know what is going to happen, but I do not think we have seen the last of this.


The VB 6 retirement question continues. Clearly we have a diversity of opinions...

Subject: VB6 debate

Dr Pournelle,

I was moved to write when I read the letter from Jonathan House published on Mon 14th. He missed the point completely when he said "These are scripting languages provided by a single vendor (Microsoft) that have reached the end of their support life cycle." Anyone who calls VB just a "scripting language" has missed the point.

He has also missed that point that high level languages provide the flexibility and stability that modern applications miss. Basic has always been inherently safe, no need to worry about "buffer overflows" as the compiler or runtime automatically handled it.

It was the first language that the non-professional developer could use to create an application in a windowed environment. Yes, TurboPascal and similar existed, but required serious investment in time. I "grew up" with VB, having used all the versions 1,2,3,4,5 and 6, to develop commercial software for a large software house, as well as provide 'glue', mission critical components for systems written in Java, running on the cost effective Windows Server platform. Linux and other *nix systems still cost lots of money in support engineers and time, compared to the number of Windows engineers available.

I've signed the petition Robert Conley links to, and I am happy to say that VB3 applications, (and VB6) applications function well on Vista, and can often be run using the freeware WINE on Linux.

Whilst I understand the argument Mr Thompson and others make about open source, I cannot reconcile this with the need to make a living. I suspect both yourself and Mr Thompson would be against giving away your intellectual property in your books, why is software any different? Many "one man band" software developers used VB and continue to do so. "It just works".

Many large companies rely on in house applications written by staff who are not professional developers, but have produced something incredibly valuable. This is the legacy of VB. It was an enabling technology. How can we let that vanish?

I'm in my 30s and grew up with BASIC, touched on Pascal and was taught C in the classroom. It was when working commercially with VB 3 with experienced programmers that taught me how design and coding practices produce maintainable code, not the language. Today I meet many graduates, and experienced IT support staff, who have never seen code, never been through the thought processes, and I wonder if within 20 years the skills for coding will be lost. These skills in problem organization and resolution can be applied to any part of the IT industry.

Perhaps we should petition Mr Gates directly, and ask when he personally will be releasing Microsoft BASIC for Vista, or will he release the rights to the language ?

James Chamier


Subject: Further Replies to the situation on VB6

I disagree strongly with some of the statements Mr. House has made concerning the situation with Visual Basic.

First and foremost, I would hardly characterize Visual Foxpro and VB as "key" programming languages. These are scripting languages provided by a single vendor (Microsoft) that have reached the end of their support life cycle. Yes, there are quite a few applications out there built on these languages (I've done more than my fair share), but their disappearance will have nowhere near the impact of the removal of a non-vendor specific language such as C, C++ or even COBOL.

The fact is that the Visual Basic is not a scripting language. There is a variant called Visual Basic for Application (VBA) that is packaged to be used as a scripting language but the langauge itself originated in the Visual Basic for Windows series of programming IDEs. I am not going into detail about with Visual Basic can and can't do. I will point out the attitude shown by the opening paragraph. It is this very attitude that caused the demise of Visual Basic 6.

Many moons ago I was part of a team faced with a decision to continue development in Visual Foxpro, or to migrate to a more "modern" programming language. One of the key motivating factors for this decision was the fact that the Foxpro language was only supported by a single vendor, so our fate would be tied to theirs. We eventually settled on Java as our next programming language.

The BASIC language that was at the core of Visual BASIC has long been supported by Microsoft since the days of their first compilier. Every version from the 8 bits days, to QuickBASIC/PDS, and finally to Visual BASIC has been evolutionary rather than trashing with what has gone before. Microsoft had many opportunites to totally ditch their heirtage of supporting the BASIC language and they didn't. That is until 2002. The only reason that Visual FoxPro and Visual Basic are no longer modern is because they have been ceased to be supported. The issue here is not technical. Visual BASIC and the COM framework underneath could have been continued to be developed.

The issue here that Microsoft actions destroyed the single most popular programming language on the planet. Despite months of warning and pleading by various noted Visual Basic developers they released an incompatible product. But unlike Borland or other programming tool vendors they have so many streams of revenue that they are insulated from the immediate consequences of their actions.

In that same article David Lambert expresses concern that he is going to eventually have to rebuild his project, presumably in a new language. Again, I fail to see this as a real problem.

Here is the dirty secret I found in maintaining the same application (CAD/CAM for x-y metal cutting machine) for over 20 years. That software, like mine captures knowledge. Knowledge that not just represented by simple algorithms and procedures but how all the various bits fit together. Software is complex and its creation is still an art not a science.

Every time you rebuild an application you throw this knowledge away. I rebuilt our application two times. The first to transition from HP's Rocky Mountain BASIC to Visual BASIC, the second from 16 bit VB procedures to 32 bit object oriented system. Every time I did this something was lost in the process. All of our bug tracking, and trouble shooting procedures had to be re-done and re-started.

The 16 bit to 32 bit object oriented system change was prompted by three things. First we had memory limitations in our 16 bit VB version, second there were areas like file import, reports, and shape creation that were subject to continual change and revision, and last I learned a lot in the ten years since the first conversion and had a design that would be literally our last ever.

How can a design be the last forever? When it built so that its important pieces are modular and only operate through well-defined interfaces. So now file handling, machine control, reporting, and shape creation are handled by reloadable libraries. The UI sits on top of an interface that is VB Form agnostic and all the VB Specific graphics and forms are in one area.

So if I have such a great design why I am so upset at Microsoft? Because if Microsoft made a compatible product then my costs would have been much lower. The new features that were compatible would have helped tremendously over the years. By doing the actions they did my programming and support costs went up by an order of magnitude the day I am forced to upgrade. This compounded by the fact that after analyzing how .NET actually worked instead of drinking the marketing kool-aid. I found that the incompatible changes were well.. bullshit.

For example

In VB 6 integer compiles to a 16 bit variable In VB.NET integer compiles to a int32 a 32 bit be variable Integer has been a 16 bit variable since the days of 8 bit BASIC. Dim I as Integer or Dim I% has produced a 16 bit variable always until 2002.

Before Java and C++ folks chime in, I will remind you that this is the BASIC way. No different than C++ lack of property methods for their classes. (C++ has to write getMyProperty and setMyproperty functions if they want to use property methods)

Another example is GOSUB..RETURN. In VB.NET it is gone. Again before the C++ and Java folks point that that GOSUB..RETURN is unstructured. I will say that for good BASIC programmers we used GOSUB..RETURN for the many of same reason that lisp, Java and other such languages uses nested subroutines/functions. It is weaker and more prone to abuse but it is also a feature we had since the 8 bit days.

These are not the only important features missing. The graphics system works totally different with no hint of the math needed to make it work like VB6. The printing system uses a completely different structure that require a total re-write. Yet five years later they are able to produce a near working version of the VB6 print engine for .NET.

Both of these features can be handled by today's techniques used in creating compilers. Ruby.NET, F# and a dozen languages with vastly different syntax and constructs produce IL (Intermediate language) A Microsoft teams that understood the history of BASIC and the Visual BASIC variants would have developed a .NET language that would supported those constructs and more.

Bottom line, the disappearance of VB and Foxpro are significant to those that still depend on those languages, but I doubt their demise will cause much wailing and gnashing of teeth to the software development community as a whole. If anything, perhaps this will serve as a wake-up call for those that base their software development efforts on the platform of a single vendor, or those that are spending a lot of time and money keeping those old applications limping along.

The bottom line is that Microsoft is the 800 pound elephant in the room and when it sneezes we all catch colds. Folks no matter how much you despise Windows, PCs and Microsoft, if you are a commercial vendor you must deal with Windows in some form or fashion. What you see being developed for the internet is only the tip of a very large iceberg that is the software industry. That most of the software isn't the horizontal application like Office, Firefox, Google, Apple's iLife. But vertical market applications made by hundreds upon hundreds of developers working in narrow markets all across the nation and the world. Most of them using Microsoft Windows, many of them Visual BASIC. The last five years have given us bad colds.

Thank You
Robert Conley


Hello,

This Monday's mailbag (May 14th) touched an interesting subject: Visual Basic

Since I am using this language now and have been using it since Version 1, I thought I'd share my thoughts about it.

Many people that have moved on to .NET seem to have an ill conceived notion of VB6 developers thinking that we are too stupid or too lazy to move on to .NET. We are considered rogue developers who have chosen to cling on to a dying technology. While this may be true with some it is incorrect to generalize these beliefs across the board.

Since I can only speak for myself, I will document my own thoughts on this. The question is: why move on? Why haven't all COBOL programs been updated to a more recent technology? Basically, two reasons: Cost and practicality. The cost not only involves the development process, but also the tools that will be employed and if necessary, the upgrade of hardware. Practicality tells us that is if it isn't broken, don't fix it. While legacy applications may be more complicated to enhance and maintain, in most cases the majority of the core logic is functionally solid. Only when a total rewrite is necessary is it justified to change programming environments. I know of companies that have a decade of time and work-hours invested in Visual Basic 6. Microsoft, unfortunately, did not provide a path to make switching from VB6 to VB.NET remotely easy. The best way to move to .NET is to rewrite the application, not to mention the only way. For some, this is a totally acceptable solution, for others this is not even an option.

Some of the remarks made in your Mailbag seem to imply that VB6 developers have some sort of emotional attachment to the technology. Speaking for myself, I could not care less about which technology I use, but then again, I should care as much as necessary because my clients depend on it. Moving on isn't as simple as uninstalling the obsolete technology and installing the greatest and bestest (sic). Factors that I am mentioning here have to be taken into consideration. Personally, I do not mind programming in any language, just as long as it satisfies the client's needs which are usually "better and cheaper". I have had the opportunity to program using assembler, C, Pascal, some C++, some Java and of course VB. Regardless of what language I may prefer, I have to take into account the investment that my clients have already made. What are my chances of landing a project using Java if the client has standardized using C#? At this time my client has a substantial investment in VB6 and I do not see this changing in the near future, but this isn't simply because we don't want to or are too blind to see the benefits of newer technology.

The biggest problem with killing off VB is that since this is a proprietary technology, no other company can come to the plate with a compatible alternative because it will infringe on MS' intellectual property. While this carries little concern with some, others see it as though MS has abandoned all the developers that use this technology. What this means for those individuals or companies that have sizable investments in VB6 is that they are left without a path to the future, but even worse, they have lost trust in MS. If there is no path to migrate from VB6 to VB.NET now, what guarantees the developer (or company) that this will not happen again when .NET's successor is ready for prime time. Most believe that the solution is using a technology that is not proprietary.

Whatever the solution, the developer usually follows the tendencies of his/her clients, using the technologies that are available. It is for that reason that the individual that carries out the task should be knowledgeable enough to exploit the technology that will be used and be not criticized if that technology is not the norm.

Thanks
Salvador


Jerry:

Regarding the code retirement thread in CMR Mail today:

I grew up mostly on Fortran 77 back in school, then ended up in positions where I had to do no code development for about 15 years (MS Excel or Mac Resolve were adequate).

I remain very strongly science model applications oriented, and when faced with the choice of starting a project from scratch without expert support I fall back to Fortran. Linux g77 and Force Fortran allow me that freedom, though I've also had warnings about compilation errors in the interpretive Fortran compilers. I'm slowly working on C, but (except when editing C/C++ by others) my C looks a lot like Fortran.

J.

Alas, I haven't time to comment. I will repeat that I am convinced that software ought to be written in structured languages with strong typing and range checking so that many errors left to debugging in C are found by the compiler. And I think it high time that the Pentagon revived the Ada project. Ada could be turned into a very useful and powerful language.

Of course I doubt that will happen because of bureaucratic reasons.


I have received a good bit of advice about Outlook, including good sense from our frequent correspondent Bob Holmes:

Subject: Outlook performance and focus problems

Jerry,

Your problems with Outlook are caused not only by the poor design and implementation of Outlook, (not the design of the features of Outlook, but the underlying code architecture) and the problems that are littered throughout Windows. The multi-tasking capabilities of Windows are, to put it charitably, lame. It would also appear that rather than blocking a thread of execution with a semaphore waiting on an event the coders at Microsoft may be setting a timer making the assumption that some task cannot take longer than the timer regardless of the speed of the system and then unblocking the thread. I cannot explain long waits with essentially zero CPU utilization any other way unless there is some problem with the Windows Performance Monitor.

The poor design and implementation of Windows code appear to the the result of a very strong Not Invented Here (NIH) complex at Microsoft. Rather than use the knowledge and art of Operating System design that has been accumulated over the last 50 years or so, Microsoft evidently believes that they can do it better. It is painfully obvious that they can't!

One thing that is puzzling is that Dave Cutler was hired from DEC to oversee the design and implementation of NT. As one the "Fathers" of VAX/VMS one would think that Cutler would have had some chance of breaking the NIH complex. Of course, the NT project was already well underway when Cutler arrived on the scene. It is apparent from the resulting OS that Cutler's influence was far from profound.

One could go on for literally pages and pages about the serious and inexcusable errors in Windows. One of the more egregious problems is the modal dialog box appears, not on top of the parent windows, but underneath it totally blocking the application that spawned it. Being a modal dialog box, the parent process will be unresponsive until the user dismisses it. Of course the user can't dismiss it because the user cannot see it or respond to it. The dialog box has focus and the basic rules of Windows say that the window that has focus will be on top. Unfortunately Windows doesn't follow its own rules.

It is now time for all technology journalists that panned OS/2 to say hundreds of mea culpas. It was their bashing of OS/2 that contributed to the rise of Windows as much as the marketing ineptitude of IBM. With a reasonably viable competitor, Microsoft would have been forced to do something about the lameness of Windows or lose significant market share. We have two hopes for holding Microsoft's feet to the fire at this point, Apple and Linux. I don't see Linux playing a significant role in the home anytime soon, but Apple seems to be playing reasonably well there. Linux is gaining some traction in the enterprise environment. However, it still isn't enough to have really gained Microsoft's full attention. If many enterprises are holding off upgrading to Vista and decide to stay with XP for the long term, this just might gain Microsoft's attention.

Given the important features that were announced for Vista and then dropped, I have serious doubts about Microsoft's ability to correct the serious shortcomings that are embedded in Windows. Even starting from scratch and developing an entirely new code base for Windows may be beyond their current abilities.

Bob Holmes


There's also this:

Subject: I don't understand

Why are you even considering upgrading to the latest version of Outlook?

Have you ever known Microsoft software to become smaller and faster over time? My experience is that each new version of a Microsoft product has more features and bloat and requires a faster, more powerful computer. There are three reasons for this: 1) its easier to write programs if you disregard resource consumption, 2) adding features and increasing integration is the Microsoft business model to prevent competition and 3) the hardware makers (Microsoft's true customers) love it.

Can you imagine what the young Jerry Pournelle, sitting at Zeke, would think of continuing to use software that, when just handling some email, could bring a computer with multiple 32 bit gigahertz CPU's and hundreds/thousands of megabytes of RAM to almost a halt?

Reading your site over time, I'm amazed at how much effort you've spent dealing with outlook internals such as .pst files and all the other trappings/failings/features of outlook. Do you think your readers are interested in learning more about software that can, at almost any time, require hours of effort to sort out? Or software that might just upgrade itself without notice or warning?

It's long past time to make a switch. Unless using Outlook is living up to your motto of "doing stupid things so you don't have to".

M Dempsey

I can only reply that habits are hard to break. Outlook has been useful even with its problems. Taming it by restricting it to one CPU has helped a lot, too. Even so, I often find it annoying. With luck I will shortly have time to reconsider everything.

When I do, I am sure to have lots of alternatives suggested.

Morning Jerry,

I've read your growing frustration with Outlook, and wanted to share some thoughts on two alternatives.

Thunderbird: A good all-around e-mail client, with decent (but not great) spam filtering. The profile management and file storage is confusing, and I've had my database corrupted twice, resulting in lost e-mail. The messages are stored in a format based on the mbox standard, and can be converted to may different programs. I never had performance issues with it, no matter how many e-mails were in the database. There is no archive functionality available, so that's a big drawback - you have to manually create a new file and move messages over to it. You can relocated the stored files rather easily using the profile manager (which itself is hard to find - it's only available as a command line option). Available on both Mac and PC, and from my experience, the data file format is compatible between the two platforms.

Net: Decent 'free' alternative. No calender, address book is minimal, but data files are cross-platform.

Mail.app (i.e. MacMail), plus Mac AddressBook, and iCal: As part of my move to the mac, I experimented with these for a while, then after another database problem in Thunderbird (version 2), I made the jump. Converting the e-mail is a bit complicated (I can send directions and the perl scripts if you'd like), but all of my T-Bird e-mail came across intact. Now that it's running, it's like everything else on the Mac - it just works. There are some nuances that I don't care for (most of which are supposed to be fixed in Lepoard, due in October). The spam filtering is much better than Thunderbird, and the rules wizard seems to be robust as well. You can relocate data files (after some tweaking) to live anywhere you want.

Net: If you're willing to go Mac only - take a look at these. Downside is not PC compatible.

And just a note on data files - one option (and this works even with Outlook), is to put the mail on an external 2.5" USB drive (backed up regularly of course) and point the program at it. That way you just plug that drive in to any machine and your mail is there - no copying required.

Cheers,

Doug

And that ought to be enough for this week. Now I am off to DC.