|
A couple of things that I feel should be pointed out, as someone who switched from VB6 to .NET and now am managing an iSeries environment. I really believe that the missing piece in the discussion is the user interfaces and their impact on technology. VB6 in it's day and now .NET are attempting to provide cutting edge interfaces through fat client and web browsers. I don't think that RPGIII has nearly the same mission, making it a much easier task to maintain backward compatibility. From an interface perspective, it is not attempting to keep pace. Our users are starting to reject green screen, and I think it will only get worse over time. .NET is an easy way for us to provide friendlier custom looks at our iSeries data for managers and other information users, prolonging the life of our core applications for the data generators out in the plant who are perfectly comfortable with the older interfaces. I think they compliment each other. Java could also provide this function, as Joe suggests, but I am put off by the different class libraries, IDE's and other underlying technologies being advanced by the different players now. Choice is a two edged sword in development tools. Joe, I also don't think it is fair to judge backward compatibility by comparing 10 year old games to System 38 programs. Games almost by definition are pushing the envelope in terms of the hardware they are released for, nearly guaranteeing they will crash and burn on later hardware. There is a planned obsolescence in the gaming world that makes this a poor comparison. We also need to remember that Microsoft only has full control of one side of the equation, the software. IBM retains full control of both the hardware and software, making compatibility much easier again. Apple is currently using this argument to resist the idea of Mac OS running on standard PC hardware, by the way. I would also submit that part of the problem was that VB6 and COM were not great products. VB6 had a lot of quirks and feeble object orientation capabilities. I am not at all sure it was a model worth continuing. DCOM and Visual Interdev were even worse. Yes, Microsoft could have done a better job of backward compatibility. I used the conversion tool to open some of my VB6 projects in .NET early on, and decided that the resulting code changes left me with an indecipherable mess. I was lucky, I only had a few applications to rewrite. However, from a programming standpoint, .NET is a far superior product compared to the things it replaced. Pure speculation on my part, but I really believe the .NET framework will have a longer life than the VB6 runtime because it is a much firmer foundation than the disjointed set of tools that MS had before. I really don't enjoy defending Microsoft, they have done a lot of lousy things to their users over the years, such as $500 office suites, DCOM, Windows ME and Software Assurance among others. However, in this case I think they are getting something of a bad rap. Thanks for a great forum. Jim Reinardy Badger Meter, Inc. -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta Sent: Thursday, June 16, 2005 4:18 PM To: 'Midrange Systems Technical Discussion' Subject: RE: RPGIII compiler vs Visual Basic > From: Walden H. Leverich > > If you called up > IBM and said the chain opcode wasn't working in a RPGIII program and you > wanted them to fix it as part of your warranty think they would? Absolutely. > Also, the issue w/Longhorn has nothing to do w/VB running, but rather > has to do with the runtime DLL (VBRUN60.dll) being distributed as part > of the OS. If you distribute the DLL yourself it should continue to run. But won't be supported. Walden, you and I are disconnecting major here. Maybe you don't understand how OS/400 works, being as you've been ensconced in the Dark Side for so long... if I were to take an old S/38 program and restore it on a brand spanking new iSeries and it caused a machine check, I could call IBM and expect a fix. Not only that, but for the most part, I could make changes to the source, compile it, and expect THAT to work. Do you understand this concept? Do you understand the incredible magnitude of this capability compared to what passes for support in the Microsoft world? > Of course, the exact answer to what will and won't run in the final bits > of Longhorn can't be answered until it's released, but early betas of > Longhorn have been seen running VB apps. And here's another difference between the philosophies of the companies. IBM expects your old programs to continue to work, Microsoft guarantees no such thing. You yourself have no idea what the next release will support, whereas I'm comfortable that my programs will continue to run and run and run (that's also one of the primary reasons I believe in make vs. buy, by the way). > Part of the problem w/shipping the vb runtime as part of the OS is that > it then falls under the support timeline of the OS. For example, since > the vb runtime shipped w/XP and XP doesn't end extended support until > 2011 MS has to support the VB runtime until 2011. Says who? In fact, I'll bet you fifty bucks right now that you will NOT be able to run VB6 programs on any new Windows machine shipped in 2011 (let's say a Dell shipped with Windows pre-installed). I absolutely, positively guarantee it. Let's pick a nice, juicy VB6 application today, and stick it in a time capsule and see if it runs in 2011. (You can put it in a ZIP file and store it on an iSeries, since you know that will still be running in 2011.) Anybody else want a piece of this? > Since MS has stated > that support timelines are roughly 10 years post release if Longhorn is > released in 2006 and contains the VB runtime that would require MS to > support it until at least 2016. And remember, "support" means FIX, not > RUN. Microsoft can say whatever they want, but it's just words. I'd be interested to know how many programs written in 1995 run on Windows XP. I know most of my games don't. And yet, I KNOW that programs written in 1985 in RPG will run on my iSeries, AND I can modify them and compile them and run them today. This just isn't sinking in, is it? Joe -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.