|
JCapper Message Board General Discussion
|
| Home |
Register
Log In |
| By | Windows Updates Equals Computer Hell for Developers | |
| jeff 3/18/2014 7:24:12 PM | Fair warning: Unless you are a programmer actively maintaining legacy software written in Visual Basic (VB6 or VBA in Access or Excel)... This post does not apply to you. You should stop reading now - go no further - and have a great day. For those of you who choose to read this post, before you do so, I should probably point out that none of the problems described below impact compiled versions of JCapper (.exe files and .mdb files) installed by downloading from the JCapper site. ALL of the problems described below are limited in scope and impact to uncompiled versions of programs like JCapper (.vpb, .frm, .bas files/source code, etc.) as they exist in the VB6 Dev Environment. The rest of this post is about 50 pct me venting - and 50 pct me leaving a searchable trail in the event I have to go through this again at some later date (most likely on some new machine I haven't purchased yet.) JCapper is written in VB6. (I began writing it in earnest in the late 1990's.) Sometime around the year 2000 (14 years ago as I type this) Microsoft began making waves about dropping support for Visual Studio 6 (the Dev Environment that VB6 is compatible with) in favor of Visual Studio.net (which hadn't been rolled out yet)... although early versions were 'leaked' to the software development community. Fast forward to early 2005: JCapper had been out for more than a year. I was selling copies of it and (more importantly) actually using it to generate an income stream at the windows. About that time Microsoft officially released a version of Visual Studio called Visual Studio 2005 and I had a decision to make. I could either recode 100's of 1000's of lines of vb6 code to make JCapper VB.net compatible... or I could maintain JCapper as a VB6 app. Eventually I chose the latter option because JCapper contains so many subs and functions and so many lines of code that converting it from VB6 to VB.net is a project that will (literally) take several years. Using JCapper for live play is more important to me than selling copies of it - making the idea of a significant rewrite a complete non starter for me. Fellow horseplayers and developers sometimes ask why I continue to maintain JCapper as a VB6 app. Now you know why. A Clean Machine A while back I bought a new Lenovo laptop and posted a review about it. One of the smarter things I did with that laptop was operate it as a "clean" machine. By "clean" I mean strict adherence to the following set of rules: 1. The ONLY apps allowed to be installed on it are the JCapper Dev Environment (VB 6.0), JCapper itself (the download package itself as downloaded from the JCapper site), and Microsoft Office (Word, Access, and Excel.) 2. Windows Auto Updates are turned OFF. 3. NEVER connect the machine to the Internet. (That way, the ONLY software installed on it is stuff I put there myself.) Computer Hell Note that I used the phrase "Computer Hell" in the title of this post. (So yes I'm pissed off.) All of the problems posted about below began when I broke rule #3 above... A couple of weeks ago the monitor of another (completely different) laptop I was using for live play went dark. Other than "it doesn't work" I was unable to diagnose the problem myself and took that machine to a local repair shop. ($150 and 4-5 days later I had a working machine back in my possession.) It was during those 4-5 days that I broke rule #3. I connected my "clean" machine to the internet so that I could use it for live play. I posted above that Windows Auto Updates were turned OFF. (Meaning that the machine wouldn't download and install some new update without my permission.) What isn't posted above (and something that hadn't occurred to me) is that Internet Explorer (the web browser) has a similar setting that wasn't turned off - and that Internet Explorer (the web browser) will download its own Windows updates. Historically, some of these IE web browser updates have caused problems for VB6 and VBA developers because sometimes the update behaves every bit as badly as a "regular" Windows update. Q. What do I mean by that? A. Specifically - unknown to the developer - the update unregisters or cordons off DLLs and/or OCX files needed by programs written in VB6 and/or VBA for Access or Excel. As a developer who has spent thousands of dollars on Microsoft products over the years - and as a developer who has spent untold 1000's of hrs using Microsoft products over the years as my Dev Environment of choice - I can't help but think how utterly deplorable it is on the part of Microsoft to publish AUTO updates that behave in this manner. In my opinion, if there truly is some vulnerability in a ProgressBar that enables a hacker to gain remote control of a client machine: The correct thing to do in an auto update is to include a replacement ProgressBar where the security flaw has been eliminated. The deplorable thing to do is publish an auto update that disables programs written by developers who put their faith in Microsoft by purchasing and using Microsoft products. You can probably guess what happened next. Even though I had taken precautions to avoid this type of event... Internet Explorer isn't my default web browser. I'm partial to Chrome and that's what I was using after deciding to use the machine for Live Play. But a couple of Saturdays ago the video at a track I was playing wouldn't render. So I launched IE to see if the video was watchable using a different web browser which it wasn't. Unknown to me, IE began downloading a series of updates that it scheduled for install the next time the machine was restarted. Early Warning Signs The first sign of trouble happened the next morning when I fired up the machine, launched VB6, and tried to load the VB project for the Wager History Module. I had intended to put some finishing touches on it so that I could finally publish the CSV Ticket Import Screen as part of a JCapper program upgrade. Instead of the project being loaded, I was met with a series of error messages and log entries. I was not overly alarmed... at least not at first. You see, only a handful of JCapper projects wouldn't load or run in the VB6 Dev Environment on my formerly "clean" machine. The VB6 projects for any JCapper module that had a ProgressBar or a RichTextBox wouldn't load or operate. But those same VB6 projects would load and run on other "clean" machines. More perplexing was that VB6 projects for modules that didn't use a ProgressBar control or a RichTextBox... those did continue to be operable in the VB6 Dev Environment on the formerly "clean" machine. Being an experienced developer (roll eyes) I had encountered similar periods of down time in the past - all of them resulting from Windows Updates. And all of them (eventually) fixable. But the longer I tried different things and attempted to solve the problem myself without success... the more disconcerting the problem became. (The longer something like this goes on the more you just want it to be over!) JCapper modules that use a progress bar or a RichTextBox? The Main Module for one. The Data Window, The JCapper2 Imports Module, and the WagerHistory module for two, three, and four. There are others but hopefully you get the idea... Not being able to solve this meant I would have to switch the JCapper Dev Environment back to an older (slower) machine. Doable yes. But yuck. Each time I attempted to load a VB project with a progressbar or a richtextbox on a form I got a series of error messages and entries in log files similar to the following: Class MSComctlLib.ProgressBar of control ProgressBar1 was not a loaded control class. I will point out that I performed 100's of Google searches for the specific phrases appearing in the various error messages and log file entries. And was kind of chagrined to discover that even though I am an experienced developer NONE of the suggestions/solutions that I stumbled across on various VB forums/msg boards, etc. fixed the problem or worked on my machine if one followed the steps from the solution being offered exactly the way the solution was posted. It got to be a daily routine... spend a couple of hrs a day for 7-10 days poking around the web reading up on different things to try - hoping one of them might work. One of the first solutions offered was a suggestion to uninstall Windows Updates... specifically the ones whereby IE9 had been upgraded without my permission to IE10... and from there to IE11. So that was the very first thing I tried - and it resulted in one of the more frustrating experiences I have had with Windows... EVER! During my first attempt to uninstall the Windows Update that had taken me from IE10 to IE11... My screen went completely blank except for the following lettering: PREPARING TO CONFIGURE WINDOWS... PLEAE DO NOT TURN OFF YOUR COMPUTER And it STAYED that way - not changing at all - with the 3 dot characters after the word Windows above blinking for hours on end. I did my level best not to turn the machine off. In fact I left it untouched overnight. But the next morning when I woke up the machine was still in that state. I had no choice but to power it down and restart it. For those of you who are still reading, I DO maintain ALL of the JCapper source code in off site locations. I also have a collection of original CDs for the various versions of VB6 and Visual Studio that were both purchased and/or given to me by Microsoft Reps over the years from when I was working 9 to 5 in the developer community. I also have quite the collection of older machines... various parts too. Meaning that if need be I have the ability to get a JCapper Dev Environment up and running on another (older) machine. But it seemed like a shame to have to do that - especially given the fact that I have a collection of newer machines too. So I kept at it... spending a few hrs each day day poking around the web reading up on different things to try - hoping one of them might work. Finally, TODAY, the light bulb switch in my head flipped over to the on position. I'd read enough threads about type libraries - like this one - that I was convinced one of the Windows Updates installed by IE (the web browser) when it updated itself had unregistered one of the type libraries needed by Windows to render the interface for the ProgressBar and RichTextBox controls found in the VB6 Dev Environment. So I went back and re-read the following thread that I had stumbled upon several days ago: VB6 forms with ProgressBar fail to load -closed- From there I did some further reading about Type Libraries. And armed with some relevant background info about registering type librabries, I went back to the following thread: How to register a legacy typelib (.tlb) on Windows 7? And from there I mapped out the following solution: 1. I did a search of my c:\ drive looking for various programs capable of registering type libraries. I found a copy of a program (filename RegTLibV12.EXE) capable of doing this. Link to screenshot: Click here 2. I copied the above program from the location where I found it to my c:\Windows\SysWOW64 folder. I copied it there because the type library (filename: msdatsrc.tlb) containing the interface for the VB6 progress bar is based on 32 bit technology and c:\Windows\SysWOW64 is the folder in WIN7 for legacy 32 bit apps. The type library itself (filename: msdatsrc.tlb) was already there but there was no .exe on that folder capable of registering type libraries (or .tlb files.) 3. I created an elevated shortcut to a command prompt. Link to tutorial click here. 4. I right clicked the new shortcut created in step 3 above, selected Run as Admin, and executed the following two command lines from the cmd prompt: cd c:\Windows\SysWow64 regtlibv12 msdatsrc.tlb And (after burning more hrs than I care to admit) received a registration successful message! Link to screenshot: Click Here. From here I launched VB6 and loaded the project for the WagerHistory Module. I still received error messages upon load but THIS TIME - unlike attempts over the past 7-10 days - I WAS able to use the Components Interface to select "Microsoft Windows Common Control 6.0 (SP6) from the components list - which DID allow me to run routines involving the ProgressBar (as designed) without error. The above solution appears to have worked for ALL of the other VB6 projects that had become disabled as a result of IE updating itself without my permission. Notes to self: • As a VB6 developer ALWAYS maintain at least one newer machine as a "clean" machine. (And never allow that machine to be connected to the Internet for any reason whatsoever.) • In the event VB6 throws error messages saying "object library not registered" when attempting to load a project or when attempting to add a control to a form: The very first thing to suspect is that someway somehow a Windows Update was allowed to run and that said update cordoned off dlls and/or ocx files related to a control being used in the VB6 project. Windows Updates Equals Computer Hell for Developers... Rant over. -jp . ~Edited by: jeff on: 3/17/2014 at: 10:47:40 PM~ ~Edited by: jeff on: 3/18/2014 at: 6:28:52 PM~ ~Edited by: jeff on: 3/18/2014 at: 7:24:12 PM~
| |
| Buckabeer 3/18/2014 6:39:43 AM | Jeff --after all that, you deserve a good rant, and a pat on the back! --nice job
| |
| Caveat 3/22/2014 9:32:32 AM | FYI If anyone needs to have a "internet less" computer You need to disable the wireless card and the network adapter in the control panel/ device manager... and nothing should get thru
|
| Reply |
|
Copyright © 2018 JCapper Software back to the JCapper Message Board www.JCapper.com |