• (nodebb)

    They're very pessimistic about their sales forecasts. 1500 orders in a whole year? Unless they're selling diesel engines for cruise ships, it's a very low volume.

  • (nodebb)

    Yikes. Imagine being so out of touch that A) you still use a shitty DOS program and B) when you decide to port it you pick VB6, another dead platform, instead of like VB.NET.

    The sad part is places like this actually exist and are stuck in some kind of weird time warp.

  • Vilx- (unregistered)

    My guess: The replacement project started at around 2002. The PDFs came later.

  • Beezle Snort (google)

    You would probably be stunned to learn just how much legacy VB6 code is still out there, and still being used on a day-to-day basis.

  • (nodebb) in reply to Beezle Snort

    You would probably be stunned to learn just how much legacy VB6 code is still out there, and still being used on a day-to-day basis.

    I wouldn't(1), but equally I would be displeased if someone told me to make new VB6 code in 2014. (As opposed to a more recent version of VB. Almost any version of VB.net is a better choice for new code.)

    (1) I formerly worked at an outfit that, when I joined them in 2003, had tens of millions of lines of Fortran code, which was, at the time, being actively developed. (To their credit, they did, later, ban adding new Fortran source files. The dedicated Fortranists subverted the intent of that ban by writing their new functions and subroutines inside of existing semi-related Fortran source files.)

  • (nodebb)

    I would not be suprised if the "orderyear" and the year in the folder path has some "interesting" edge cases. PErhps the orderyear was when placed, but the filing was when paid.... (I have seen stranger things)

  • Brian (unregistered)

    In 2008 I was working on code for Windows CE written with eVC 3. The company had gotten a special extended support contract from MS, and even that was close to expiration.

    They were also subject to PCI requirements, and one of the PCI rules is that you can't use an unsupported OS. I left before the consequences of that dilemma really hit.

  • Grayzzur (unregistered)

    Is it bad that I have a copy of "Hardcore Visual Basic" by Bruce McKinney collecting dust?

  • Darren (unregistered)

    We've still got a 16-bit DOS application (used to be two until very recently) running in our production environment that is used for managing leaseholder accounts. The original code has a copyright notice of 1991, but it has had updates every year to comply with changes in legislation.

    For reasons which I can't begin to explain or comprehend, the team who use said software consistently refused to move to anything newer - and the directors never forced them - so I've had to support running a number of 32-bit Windows 10 VMs to allow them to continue to access their software while working remotely. Had to spin up a number so that we can have one VM per user as the software bombs should two users on the same machine try and access it - IIRC it was something to do with the environment variables it creates having to be unique in both name and value. Which is nice.

    You don't even want to know about the hacks and bodges required to get 30 year-old software running under a Windows environment. Just thinking about the grief that I went through to get the software to print to anything other than a 25 year-old LaserJet is making me sad. Hell, even getting that LaserJet to work was a massive pain - you can imagine the heartache of trying to use a modern MFD.

    Thankfully, they've now finally been 'persuaded' to move to something from this century. The target completion date? April 2022...

  • LCrawford (unregistered) in reply to Darren

    |You don't even want to know about the hacks and bodges required to get 30 year-old software running under a Windows environment.

    Also trying to shoehorn the app into the 640K plus whatever flavor of Extended / Expanded memory it supports. Processor dependencies, taming the keyboard polling loop, simulating an A: or B: floppy drive, on and on.

  • Scott (unregistered)

    The place I left in 2020 was still running their main application in compatibility mode, because parts of it used some kind of weird navigation (.hrf extension? something like that) which only worked in IE7.

    One of my tasks was to figure out what was requiring compatibility (they had no idea), and create a new version. I made a parallel set of pages so it could be before-and-after tested.

    In 2018. I imagine they're still waiting on QA to have time to test those out.

  • Tinkle (unregistered) in reply to Mr. TA

    If each order is for thousands of components five orders per day might be rather busy.

  • cschneid (unregistered)

    Microsoft never breaks backwards compatibility

    Ah, sarcasm.

  • Prime Mover (unregistered)

    TRWTF of course is the fact that when the development of this system was started, VB6 was the newest and shiniest tool in the box.

  • (nodebb)

    I have a lot of fond memories of VB6. At the time, its debugger was just so much better than about any other platform out there. You could not just see what variables had what values, but run whatever code you wanted to in the immediate window while at a breakpoint, and even drag the yellow next-instruction-to-execute pointer to whichever instruction you wanted to execute next. Like, you could hit the breakpoint, see the wrong value, see what you screwed up in the code, fix the code, and then drag the pointer back before what you changed so that it would run again. Great stuff.

    But the VB6 IDE is older than scroll wheel support. Eventually there were some plugins to try to add listening the mouse-scroll messages so that the scroll wheel would work within the IDE, which mostly worked.

    If you're feeling bad about yourself someday and reading about people who have things worse than you do would cheer you up, you can browse through the VB6 tag on StackOverflow and see the poor people who are trying to convince it to use TLS 1.2, or getting it to open files at all, plus of course a lot of people who don't know what version of VB they're using at all.

  • Carl Witthoft (google)

    From TFA,

    Microsoft never breaks backwards compatibility
    Well there's some subtle sarcasm for you.

  • Wayne (unregistered) in reply to Grayzzur

    I've got a copy of Teach Yourself Visual Basic 6 in 24 Hours on the shelf behind me, right next to Teach Yourself Visual Basic .NET

    I never used them. I was a SQL Server guy, DBA and developer. I did 99% of my work in T-SQL.

  • akozakie (unregistered) in reply to Vilx-

    Exactly. My theory: Long ago someone got a limited budget to try a rewrite. VB6 was an adequate choice at the time. Ran out of budget, the results looked promising, but pouring more money into this, when the DOS version worked fine was not considered useful.

    Fast forward a few years, eg. to 2008. The DOS application is causing new hires to giggle with wide eyes. The rewrite gets a new budget. The new programmer would like to switch to something modern, but hey, most of the application is already written! No way we'll waste money to rewrite that again! Just finish the project in VB6, it's not dead yet, and it's still much newer than the DOS version.

    Side tasks, budget cuts... fast forward 2 years, the project is still not done, but the programmer is done with this BS. As far as the bosses know, the application is almost ready. So, 2010, they are looking for someone to finish it. Just bring it over the finish line, we're not going to pay for yet another rewrite, when a perfectly good application is almost completed!

    The new recruit comes, sees VB6, shudders, starts to dig in. Naturally this is not the only thing he's tasked with, so it's not moving fast. A few months later he quits.

    2014: recruiting a new programmer to "bring the app over the finish line" is a yearly tradition. The bosses don't understand why each new recruit seems to quit faster, and finishing the app in VB6 still seems like the best choice.

    Maybe they finished it by now. Maybe the company doesn't exist anymore. Who knows.

  • (nodebb) in reply to Steve_The_Cynic

    My job involves Fortran 😕

    But yes, I'd be happier if the had ported to C++ or something. Fortran is fine for numerics, and even convenient for parallelization, but the absence of generic algorithms (or language features that would allow implementing them in a useful manner) really hurts day-to-day coding.

  • Compromise?? (unregistered) in reply to R3D3

    You can always call Fortran libraries from C++... I think you can even get at the common block. There's also "f2c" (or was...)

    https://www.math.utah.edu/software/c-with-fortran.html

  • Argle (unregistered)

    I'm not sure if I count myself as fortunate or not, but I had to rewrite 30 year old DOS software in C#. Aside from the ugliness of the code, I had to get output to match the old program. This meant that I was actually introducing deliberate bugs into the output. I proposed at the outset that we just scrap the old code and let me sit down with the engineers, get their input, and write it fresh. Fortunately, I never had to do an "I told you so" at the end. The client's project head came out and told me that my suggestion was probably better than what was done. Having a humble client is actually good for my morale. I still like working with these people and the new project is fine now and getting enhancements.

    Funny aside about this project: Some of the oldest parts of the code used variables named X, D, E, F and G. The X was the product design number. That I figured out early. But the others just irritated the s*** out of me. Then I found they were standard dimensions used in the products they made. I couldn't forgive the programmer for all the other hideous names, but he got a pass for D, E, F and G... because that's what they were.

  • (nodebb) in reply to Wayne

    That's nothing. In my office, I have a book about Javascript for internet explorer 4. And I even tried reading it a little!

  • Prime Mover (unregistered) in reply to Argle

    " I was actually introducing deliberate bugs into the output."

    Well, yes, that's what you do. And you make a note of where the bugs are. Then when you have proved that the new app works exactly the same as the old app, such that the outputs are bitwise identical, then you go and fix the bugs.

    That's what we did when we rewrote a major customer's big COBOL app back in '98. Standing operating procedure.

  • Vilx- (unregistered) in reply to Darren

    Ever try DosBox? Should be easier than a full VM and take care of a lot of emulation problems.

  • Worf (unregistered) in reply to Mr. TA

    Plenty of companies only make few things per year. If those things cost $1000, 1500 orders is $1.5M revenue which can be significant for a mom and pop shop, for example.

    There's a company in the Netherlands that makes the EUV sources for chip fabrication. Costs over $100M and they produce 1 per year, tops. The machines that make OLED screens - the company that made them only makes about 5 per year. Apple got Samsung to monopolize their production for years so Apple could have OLED screens.

    For niche items, 1500 orders might actually be the production capacity. There's not enough growth to make more, but not really anyone else who can out-compete it so it's steady work.

  • Darren (unregistered) in reply to Vilx-

    Yeah, Dosbox was one of the first things I tried back when I was trying to get them off their old Win XP machines (in around 2015...). I could never get the software to run properly under it - which is probably more due to state of the software rather than Dosbox.

  • Nobody (unregistered)

    I wish I hadn’t been so late to this post. The tell was “a while ago” and yet STILL too recent.

    Then I would reminisce about the project where I updated an interpreter written for Control Data mainframes to render applications with a more modern look. I believe that my build machine was a Pentium 100 with Visual Studio 5.0 and Windows 95.

  • markm (unregistered)

    Most likely they started the project when VB6 was the newest shiniest language - and didn't upgrade to VB.net because there is a huge compatibility gap. About ten years ago I wanted to re-use a small VB6 program as the base for a new program, and the upgrade to VB.net - before changing the functionality - cost about 50% of the hours I'd spent on the old program. It's not just the new object-oriented features, which you may often ignore. The entire library is different in the function names, the calling format, and often in exactly what the function does. Getting around that without rewriting half the lines is both difficult and likely to entangle you in more problems with every further program update. I figured it was better to rewrite every function call, with any other changes required if the functionality had changed. This rewrite paid off in the long run with lower costs for each program upgrade thereafter, but I was lucky that I could hide the unexpected cost in areas of the project where I'd overestimated...

    So I can quite understand the decision to stick with VB6 once they'd started. It's not the way I chose, but it's not unreasonable. At least, not for the first 5 years or so...

  • markm (unregistered)

    There is a lot of legacy stuff out there. My first encounter with that was in 1973, I think: a company with an IBM 360 mainframe that had been running it for 5 years with an IBM 1400 emulator (to simulate the much older and weaker mainframe they had before), and still had no plans to recompile their software for the 360 OS. I don't know how much of that software was FORTRAN or COBOL (which should not have needed much change beyond applying a new compiler), and how much was 1400 assembly language, which would have been a complete re-write.

    From 2008 to 2019, I was supporting a half-dozen Z1800-series ICT testers, built around 1990. Manufacturer support ended in 1998, and these machines were older than half the people operating them. The software was a DOS program with a text-base GUI, apparently written in Turbo C. It ran on DOS, Windows 95, or Windows 98, nothing newer. If you upgraded Win 98 with support for USB memory sticks, the software would crash. (I got the machines networked so I could back up the test programs to a server rather than messing with a stack of floppies.) We happily paid $5,000 each for new computers backdated to Win 98, and guaranteed compatible rather than trying to find hardware that would work and doing the software installations ourselves.

    But these old machines made a lot of sense financially; except for the PCs they hardly ever broke down, and if needed replacement parts (stripped from other machines and reconditioned) were cheap, and an entire reconditioned machine could be bought for $15-$25,000. We tried an equivalent but entirely incompatible new ICT machine costing a quarter million. The service contract was $22,000 a year - and it broke down so often the manufacturer must have been losing money on the service contract. (Breakdowns of the new tester also meant we couldn't ship our product until it was fixed - we could afford to have extra Z1800s sitting unused just in case one broke, but the new one cost too much to tie up any capital in spare capacity.)

  • Craig (unregistered)

    That Select Case statement looks completely broken, though I don't think the VB6 compiler would catch it. I think it would need to be either Select Case True or have the individual cases use Case Is in order to work as designed. This is the sort of thing that's liable to show up in bad VB code, though. I know I've seen the like before in the context of a "why isn't this working" question. (Also... using '+' to concatenate strings... yuck...)

    Re Fortran as legacy language, unlike VB6, the language is still undergoing active development, and there are multiple maintained options for compilers.

    Re Fortran generics, you can get part of the way to generics with interfaces, but they still require the separate individual typed routines. Maybe generics are something they're working on for a newer edition of the standard; there's enough experience out there that they should be able to craft something that would work.

  • The Shadow Knows (unregistered)

    When someone says "Speaking from experience supporting VB6 apps circa 2008, it was already difficult to get it actually working reliably on any relatively modern version of Windows aside from the most basic configurations." you do have to question their actual experience. Even now it's trivial to get VB6 running.

  • Fernando (unregistered)

    "Microsoft never breaks backwards compatibility?" Try opening a .doc created with Word for Windows 1.0.

Leave a comment on “Select Orders”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article