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.
Related
I originally (many years ago) wrote my applications using VB6 on the assumption that it was a strategic Microsoft product and so I would be able to run them as long as I wanted. However with Windows 8 it looks like VB6 will not longer be able to run.
What do people think is a good strategic alternative to VB6 as a simple development environment for applications not needing Internet access (they just run on the PC)? I really do not want to have to convert the applications again in the future.
Go for .net , it runs on a "virtual machine" and it seems it will be here for long time to come. The development cycle is similar to VB6.
You can look at PowerBasic Compiler for Windows + PowerBasic Forms 2.0...
Delphi is an option and depending on how complex your programs are there are some conversion tools available.
Alternatives abound, and choosing a good one is hard enough. Forget finding a "best" one.
Some people like Jabaco, which has the advantage of targeting multiple platforms.
VB6 SP6 run perfectly on 8 full version, some kb update will stop system info and rtf tools from loading, so be careful if in case you app uses them, when doing some kb updates be careful and reimage your system regularly.
WARINING: IF YOU HAVE NOT UPGRADE FROM 8.0 TO 8.1 NOW, PLEASE DON'T, BECAUSE ABOUT 90% OF THE TOOL DOESN'T WORK. IT MAY BE SUPPORTED LATER, SO WAIT.
"The question you're asking appears subjective and is likely to be closed."
Yes this is a subjective question.
It has no answer.
I was just wondernig if I was the only one.
So... was it painful?
I just want to hear some comments.
Jag
P.S. Of course, it all depends on the app size, the language it was written, good or bad programming habits, etc...
Very painful, and a cost of several days if not weeks over time...
We had a lot of code revolving around sessions and IPC. So we were effected by the change of session 0 isolation.
For Vista x64 and 2008 x64 we also had some driver components that needed to be digitally signed with authenticode now. Which wasn't a requirement before.
We also ran into some trouble with some of our apps not having manifest files to specify that they needed to be run as an elevated process.
I had to move some registry keys from HKLM to HKCU - that was all - and I was very happy about that. About an hour or two. Less than a day form when it was discovered to when we had it fixed and in the source tree. Not sure of the line count on that C++ app.
Not huge, but not trivial
Not much. I worked primarily on a large app written in C++ and MFC. We moved to VS 2008 before Vista (waiting for VS 2008 SP1, which saved a lot of trouble), and most things just simply worked. There was one external library I found a slight problem with (compensating for old VC++ problems), but no big deal.
Except for a routine to grab a window and put it into JPEG format, which I narrowed down to a small stretch of standard code that was vetted by competent people both here and on the MSDN forum. Eventually, that problem went away on my computer, so I couldn't pursue it, but it has cropped up on others.
So, I never know when the goblins are going to come and take the JPEGs away, but other than that the transition to Vista was smooth.
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.
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.
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?