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/80838f1ca795b14ea1af48659f35166f1c1...@drexch02.corp.globetax.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.
