Up to now in my application, I've been supporting all flavors of Windows from Windows 98 to Windows NT/2000 to XP to Vista.
But because of adding Unicode in my next version, support of Windows 98 would still be possible, but very difficult.
I know there are still some of my users running Windows 98.
What are the pros and cons of me no longer supporting Windows 98?
Dropping support for Win98 opens up a whole host of new Win32 API's that you can use in your software. This will allow you to provide a better experience for the majority of your customers on newer OS's.
Continue to provide the current version of your software for Win98 users, but make it clear that Win98 will not be supported in future versions of your software.
I think most Win98 users are starting to get the message and will be upgrading soon. Also, if they are unwilling to pay for upgrades to their computer/OS, they are unlikely to be willing to pay for upgrades to your software ;)
The impact to you and your business is going to be a function of what percentage of your users are still running Windows 98, and what percentage of your support time you're spending on them. If those two variables are at or around the same proportion, I'd keep supporting it.
I think that Sherm hit the nail on the head here:
If you still have users running Windows 98, then one obvious drawback to dropping support is that some of those will inevitably refuse to upgrade. They'll either stick with the version of your software they already have, or switch to something else.
I would only add one thing to that -- anybody using Windows 98 probably isn't going to be so keen on upgrading anything. In fact, it's likely that the users you've got out there who are using Win98 are using older versions of your software anyways.
In any case, the advantages for supporting a minimum of WinNT-based Windows are too numerous to list here. The best solution here is to provide a link to the last functioning Win98-compatible version of your software to these users, but you shouldn't go out of your way to cater to people who are still keen on running a 10-year old OS.
If you still have users running Windows 98, then one obvious drawback to dropping support is that some of those will inevitably refuse to upgrade. They'll either stick with the version of your software they already have, or switch to something else.
On the other hand, the cost of developing for and supporting those users probably outweighs the additional revenue gained from it. So even though in principle you don't want any unhappy customers, in practice it may be more cost-effective to keep 99% of them happy.
The most common thing to do in your situation is to leave the customers with Windows 98 running the old version. Sometimes you just have to let go of the past.
Well, if one of your customers in running a 10-year-old OS (on presumably 10-year-old hardware), something tells me they aren't spending much updating your software.
Unless it's a private customer, paying you for custom software, I wouldn't worry about it.
And if it is a private customer asking for custom software, perhaps you should show that the prices of modern machines vs your premium for having to work with such an old system.
There are a few Unicode functions still available on Windows 98:
http://support.microsoft.com/kb/210341
Depending on your roadmap and technologies you use - it may be possible (but a bit of a pain) to branch your code. Using a decent SCM system, you could develop in your "new" branch and back-port (merge) features and bug fixes that are also relevant to the win98 branch.
It's a bit of work, but it would allow you to continue to provide new features to all customers, and not leave your win98 users out of the process.
If a customer/user is content to run on Windows 98, then, they will be content with an out of date version of your software.
Just freeze the current Win98 executable and explain in the release notes that newer features will only be available in Win2K or Vista versions.
I dont think this will upset anyone (you may know different!) and as long as you commit to fix bugs the customer should be happy.
Related
As far as I'm aware, Windows hasn't been decompiled by anyone yet. Obviously it's complicated, but surely it should've been done by now to some degree?
My thinking behind this is that if the end-user has access to the software, and the computer is able to run it, then even an obfuscated version of it must be obtainable?
I'm obviously missing something, I'm just not sure what.
There's nothing preventing Windows from being decompiled (apart from EULA and similar legal bindings, of course). As you noted, the code must run on the CPU at some time, and the CPU must read the code from memory, and you can read from memory too. Some parts of the system can be a bit trickier, since to run the OS you need to give the OS some exclusive priviledges (that's how most modern protected OSes work), but it's nothing that can't be worked around. In any case, there's not a lot of effort to prevent Windows decompilation - that would have barely any benefit, while making debugging, error reporting and similar harder. Microsoft even goes so far to provide a special debug version of Windows that's even more tailored for software development.
The main point is that there's little reason to decompile Windows. What practical use would such a massive effort have? And if you're a corporation that needs access to Windows source codes (for example, when developing embedded solutions), you can get them. Just because Windows isn't open source doesn't mean the sources aren't available.
If you're not someone who needs their own version of Windows (common in the times of Windows CE), there's even less of a reason to decompile Windows. You need to stick to the defined public APIs anyway - that's a good practice regardless of whether the software is open source or not. APIs are contracts - implementation details you'd get through decompiling aren't. They might very well change with the next security hotfix or such. This is especially important given how serious Windows is about compatibility - it's quite rare for an update (or even a new major release) to break compatibility with old software.
So, if you want to decompile Windows, there's nothing technical that's really preventing you from doing so. But you're looking at tens of millions of lines of source code that was compiled by very smart compilers, with bits of handwritten optimised assembly thrown around, tons of compatibility workarounds that might as well be outright obfuscation (remember, you don't get the comments - just the actually compiled code). Are you willing to spend a few hundred thousand hours to satisfy your idle curiosity? :P
We have two different 'suites' of software: the windows-side software and the firmware. And, unfortunately, only certain versions of the windows-side software work with certain versions of the firmware.
For example, if a customer calls up with firmware version 10 we need an easy way for everyone (techs, developers, secretaries, etc) to know what this certain firmware works only with versions 12, 13, 14, and 15 of the windows software.
We have a wiki page just listing the versions and it worked fine, but there are enough 'hiccups' of people not following the process that we needs something a bit more forceful.
We have mercurial as a versioning system, but I can't see how this would be helpful for this problem (we are fine with forcing everyone to install hg).
Any ideas of programs / setups / anything that will help us alleviate the problem?
EDIT: So far most of the discussion is what I can do with the code from now on. I'm working on fixing that, too, but what can we do about all the previous releases where I can't go back and change any code? Thanks everyone for your help so far! Very appreciated!
To add to ChristopheD's comment, one way would be to make the software check the compatibility:
either through Internet (to download the latest updated list of compatible firmware and see if one of those version is present on the local computer)
or through a simple local text file if no WAN connection is available (which is easier to communicate and update than a full application release)
You might take a look at ClickOnce deployment. It allows more advanced configurations such as minimal versions. The deployment server might be on the internet or on the intranet.
I do think that you will have to change the implementation to solve this problem anyway. You cannot force an update (if you could that would be very virus-like)
I suddenly thought of this.
Think in the case of your software developed in .NET, and as well as the .NET framework (various versions). Maybe you want to follow that.
The client's host may be installed with firmware version 10 and 11; but your application requires firmware version 12. so your installer will download and install version 12.
However if your application requires firmware version 10, and the installed version is 12, maybe version 12 will also contain files from the previous versions (non-conflicting) and thus allowing the application (which requires version 10) to run from version 12.
I hate to answer my own question, but I wanted to mark something as the answer (it's ruining my perfect score!):
All that we did (and it ended up mostly fixing this problem) is rearranging the wiki so that if you wanted a windows version, you had to select which firmware you were using (and vice versa). I guess people ignore text enough, but forcing them to click on something was enough to get them to think.
Microsoft already has a Windows 7 Beta Customer Preview Program on their MSDN site where they encourage us to: "Evaluate and jump-start your development efforts on Windows 7 Beta".
Do you feel it is worthwhile to spend my time now re Windows 7, or should I wait a few releases, or even until after Windows 7 is released?
What are the advantages and disadvantages to starting this early?
As Paul said, there's absolutely no reason not to start now. What you fix now is something less to fix later - and you also get the benefit of having an application that is deployable on an OS that over 2.5m people are expected to download and install over the next few weeks.
Of course, you can expect to run the risk of having to make minor adjustments to your program as bug fixes are implement, or as new features are rolled out, but what you do now will still save you time - even if it just saves you having to become familiar with any platform-specific constraints further down the line, when pressures from potential clients, customers, etc. will be significantly higher.
I've installed windows 7 on two computer. So far, there has only been one small issue (the software did not find a USB device). I ran the compatibility wizard and now it works fine.
They have made it easy enough for a end user to take care of.
It's basically Vista 6.2. Lots of good improvements but not a new operating system. So it's no rush to test,
I've downloaded the Windows 7 beta and will be installing it into a VM shortly.
There's really no reason not to check your stuff on it now. It's way better for you to find and fix any problems before your users do.
Quite a few comments to answers in a different post, Where are the best locations to write an error log in Windows?, gave me the impression that a lot of things regarding standard folders (%APPDATA%; %TEMP%) in Windows Vista are different from Windows XP, which should of course be taken into account when developing software that will have to run under Windows at some point.
But in my company, I do not see that happen in this decade, and maybe not in the next either. I mean, the central IT deployed SP2 only eight months ago, and any question about SP3 is met with disregard (well, if you're lucky...)
So what is your advice? Should I rewrite two modules in my current project to make them ready for Windows Vista, or should I not bother about it at all, until it is really needed?
Make them Vista-ready, if only for the fact that Windows 7 will have the same changes. Better to future-proof now when you have the chance, than later when time is critical.
Personally, I'd have a quick look at the effort level of what it would take to enable "Vista Support" in your application.
If the effort levels are acceptable based on the allotted time to make changes in your project then it's good to account for the future in any design.
You know your implementation better than anyone!
We've had some issues in-house here with shortcuts and such as they were generated in an older installation suite. It's the little things that we are currently addressing in getting our Vista Support fully up and running. I'm sure there will be some "unforeseen" obstacles you will come across as well.
Best of luck!
The big thing for supporting Windows Vista in most desktop applications is to use references like your %APPDATA% rather than hard-coding paths. That should resolve any changed folder locations. And don't do anything that requires write access in your program's install folder.
Interestingly, these rules are true for Windows XP, too. It's just that in the past it was a lot easier to get away with breaking them.
There is no need to hurry. So far it is not critical, and who knows what next the version of Windows would look like.
Since you can't foresee an OS upgrade in the near future, don't worry too much about it. You should, however, keep the potential for an OS upgrade in mind whenever you're changing code. If anything is OS-specific in a section of code when you make changes, tweak it so that it is either OS-independent or easy to locate and modify later to make it OS-independent (depending on how long it would take to update it).
If you get into a situation where you're just tackling lesser issues, consider specifically aiming your fixes towards areas that you know (or suspect might) have code that would need to be adjusted if your company upgraded to Vista or Windows 7.
Don't bother, Windows 7 is coming out relatively soon, you'd be best off waiting to see what changes they make to support that! Last thing you want is to spend time fixing things for Vista..... and then fixing them all over again for Windows 7.
If you planning on upgrading your software for Windows Vista, check out Windows Logo Program, Requirements for the Windows Vista Logo Program for Software (Microsoft Word document, 183 KB, file name Windows Vista Software Logo Spec 1.1.doc).
Is your company going to upgrade to Windows Vista at all? A lot of companies are ignoring Windows Vista and are planning to upgrade to the next Windows version when it comes out in the hopes that it will suck less than Windows Vista. If this is the case, it would be a complete waste of time. Who knows what will change in the next version of Windows. It is better to rewrite once for the new Windows than to rewrite once for Windows Vista and then again for the next Windows version.
The Free MS Windows replacement operating system ReactOS has just released a new version. They have a large and active development team.
Have you tried your software with it yet?
if so what is your recommendation?
Is it time to start investigating it as a serious Windows replacement?
Targeting ReactOS specifically is a bit too narrow IMO -- perhaps a better focus is to target compatibility with WINE. Because ReactOS shares so many of its usermode DLLs with WINE, targeting WINE should result in the app running just fine on ReactOS.
Of course, there will always be things that WINE can't emulate well (hence the need for ReactOS). In this way, it seems that if something runs in WINE, it will run in ReactOS, whereas the fact that something runs in ReactOS doesn't mean that it will necessarily run in WINE.
Targeting WINE is well documented, perhaps easier to test, and by definition, should make your app compatible with ReactOS as a matter of course. In this way, you're not only gathering the rather large user base of current WINE users, but you're future-proofing yourself for whenever anyone wants to use your app with ReactOS.
In their homepage, at the Tour you can see a partial list of office, tools and games that already run OK (or more or less) at ReactOS. If you subscribe to the newsletter, you'll receive info about much more - for instance, I was quite surprised when I read most SQL Server 2000 tools actually work on ReactOS!! Query Analyzer, OSQL and Books Online work fine, Enterprise Manager and Profiler are buggy and the DBMS won't work at all.
At a former workplace (an all MS shop) we investigated seriously into it as a way to reduce our expenditure in licenses whilst keeping our in-house developed apps. Since it couldn't run MSDE fine, we had to abandon the project - hope in the future this will be solved and my ex-coworkers can push it again.
These announcements might as well be also on their homepage - I couldn't find them after 5 mins. of searching, though. Probably the easiest way to know all these compatibility issues is to join the newsletter, or look for its archives.
I have been tracking this OS' progress for quite some time. I believe it has all the potential to really bring an OSS operating system to the masses for it breaks the "chicken and egg" problem: it has applications and drivers from the very beginning (since it aims to have full ABI compatibility with MS Windows).
Just wait for their first beta, I won't be surprised if they surpass Linux in popularity really soon after that...
Post Edit: Found it! Look at section Support Database, it's the web place to go look for whether a particular piece of hardware of some program works on ReactOS.
ReactOS has been under development for a long long time.
They were in some hot water earlier because some of their code appeared to be line by line dissasembly of some NT kernel code, I think they have replaced all of it.
I wouldn't bother with cross platform testing until they hit the same market penetration as Linux, which I would wager is never.
Until ReactOS doesn't randomly crash just sitting there within 5 minutes of booting, I won't worry about testing my code on it. Don't get me wrong, I like ReactOS, but it's just not stable enough for any meaningful testing yet!
No, I do not think it is time to start thinking of it as a Windows replacement.
As the site states, it's still in the Alpha stages. More importantly, whos Windows replacement? Yours? Your users? The former is one thing, the latter is categorically a no-go.
As an aside, I'm not really sure who this OS is targetting. It has to be people who rely on Windows software but don't want to pay, because people who simply don't want Windows can use MacOS / Linux, and the support (community or otherwise) for these choices is good.
Moreover, if you use Linux you already have some amounts of Windows software support via Wine.
Back to people who rely on Windows software but don't want to pay. If they are home users they can just simply pirate it, if they are large business users they already have support contracts and trained people etc. It's hard enough for large businesses to be OK to update to new versions of Windows, let alone an open source replacement.
So I suppose that leaves small businesses who don't want to obtain illegal copies of MS software, can't afford the OS licences and rely on software that only runs on Windows and has bad of non-existent Wine compatibility.
It is a useful replacement for Windows when it runs 'your' software without crashing. At the moment it is not a general purpose os as it is too unstable (being only alpha) but people have used ReactOS successfully in anger for specific tasks already. As a windows replacement it has multiple potential uses, sandbox systems, test and development systems, multiple virtual instances, embedded devices, even packaging/bundling legacy apps with their own compatible o/s. Driver and application compatibility, freed from Microsoft's policy of planned obsolescence and regular GUI renewal, what's not to like?