Kurt: A lot of the folks here in ProFox have commercial software packages out there, and we all wrestle with the "customized for one customer" versus "one size fits all" (heh, fashion industry term) version. Successfully maintaining multiple versions of the app over multiple clients has many solutions, some easy, some hard. One of the reasons I got into SourceSafe heavily in the 90s was to support a commercial app my employer had created that had many users on a core product, several optional modules, and several custom configurations. It becomes quite the automation challenge.
Sometimes, writing the code is the easiest part of this job. Managing all the things around it is complex. For Microsoft, I suspect they could not find a situation among their very large clients where killing the 16-bit environment introduced too great a hardship. For us little guys that might have a Delphi or a Paradox or a DOS BASIC app we depended on, well, we were on our own. Workarounds can be found, and our pain is not MS' On Tue, Jun 16, 2015 at 3:44 PM, Kurt Wendt <[email protected]> wrote: > Ted - a very interesting response. This whole discussion has me thinking > about my work at my previous, previous F/T job. IT was SW for the Fashion > Industry. Although even as of early 2013 - much of the codebase was actually > based upon FP for DOS. And, when the system would run - they had the system > tweaked to run within "Windows" in Windows - but, most of the system > essentially STILL Looked like FP for DOS. White letters on Blue background. > And, I believe you could even do a thing with the Window so that it would go > Full Screen - and essentially - then - it DID look like you were running a > True DOS Program on a Windows PC. Scary indeed. > > But - long story short... > > Each year my Boss insisted on coming up with a list of New Features - and > adding that into the Package. Although - a Large part of their business was > making Custom changes to the App for the various clients. As such - the > clients with highly modified systems did Not generally get the updates. Even > though - in many instances - some of those updates were Made in the Custom > systems - then applied to the "Vanilla" package versions. > > But - it was at the end of each year that my boss would make up this New > Features list - then have us RUSH to make the changes - in order to have them > implemented (or almost ready to install) by the early Jan. each year! > > What was a TOTAL PITA - was that we had clients on current as well as Older > versions. When I was there - there were like TWO Clients still running the > original DOS Versions of the Apps - on DOS Machines NOT running Windows. I > Know - that's a Scary thought for the years 2013! So - each year we had to > KEEP Supporting OLDER Versions of the App - going back to as far as a DOS > version of the App - and that SUCKED BIG TIME! Many times it was a Convoluted > Mess to make these changes. And, each year - Clients were Constantly freaking > out when newest changes were crashing their systems - that they needed to Use > to Run their business! > > So - in the End - trying to keep things backwards compatible - from the > Programmers perspective - can be a Nightmare - which you Touched on in the > end of your last response below. > > Been there - done that... > > :-) > -K- > > -----Original Message----- > From: ProfoxTech [mailto:[email protected]] On Behalf Of Ted Roche > Sent: Tuesday, June 16, 2015 3:26 PM > To: [email protected] > Subject: Re: 16-bit ancient software on Win NT 64-bit, was: Re: Hacker's > Guide still lives > > On Tue, Jun 16, 2015 at 2:50 PM, Gene Wirchenko <[email protected]> wrote: >> >> Or maybe, Microsoft should quit cutting us off at the knees. > > I really think we agree on this issue, but seem to be using different ways to > say it. > > Microsoft as a vendor does not have my interests nor those of my clients at > heart. Their means of making money is by forcing me to upgrade to products I > don't need with features I don't want, and make me update software which was > meeting my customer's needs, often breaking working software. For large and > complex line-of-business applications, this can be costly to the point of > infeasible. > > If a vendor so poorly meets my needs, I conclude I need to seek out other > vendors. > >> Your argument could be used to say not to use VFP. > > Yes, it could, although I did not advance that point. VFP is a delightfully > capable product that fits a unique niche. Unfortunately, VFP's owner is not > interesting in promoting it. Again, if the interests of the two parties don't > align... > > I worked very closely with Microsoft as an MVP, an active beta tester, a > "partner" in various "Partner Networks" over the years, a speaker at their > conferences, and an attendee at various NDA functions, in hopes of getting > them to see that perspective. Overall, I think I helped prolong FoxPro's > life. While the product had a long run, I've concluded I need to diversify > the tools I can offer to my clients, for their benefit and mine. > >>> Commercial and proprietary OSes are going to do what they want to do, >>> not what necessarily what you want. >> >> Do you really think that I do not know this? >> > > You complained that a 1990's 16-bit utility built to run on DOS won't run in > the latest 64-bit OS that includes a 32-bit emulator to run > Windows-on-Windows for 15-year-backward compatibility. The CMD shell may look > a lot like DOS, but it is not COMMAND.COM. DOS was built with a lot of > assumptions that it owned the entire machine (all 640k!) and could do > whatever it wanted, something you can't do in a cooperatively-multitasking > machine with gigabytes of RAM and 2,4,8 or more CPUs/threads. If you want to > run DOS, you ought to run DOS, either in a VM or an emulator. Windows hasn't > run under DOS since Windows 98 (okay, WinME, but no one used that), so it's > time to run DOS differently. > > I really think your question above, "2) Microsoft broke 16-bit software on > 64-bit Windows 7. Why couldn't they have just kept the functionality?" has > a pretty clear answer: it was not in their interests. Maintaining a 16-bit > interface means a lot of very old and questionable code would need to be > brought along and re-compiled in a new OS, introducing maintenance costs and > security liabilities. Turning the question around, "why should they have kept > the functionality?" I don't see that there was a downside to them to drop it. > > -- > Ted Roche > Ted Roche & Associates, LLC > http://www.tedroche.com > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CACW6n4srJaCvF6mZwpd7s_rYY2_zAAD2wzEG6=ntm9zxoog...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
