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.
Related
As the title says, is it possible? Right now, we have Java 6 + sqljdbc4 + glassfish 2.1.1. We're planning on upgrading our Java 6 to Java 8 in order for Sqljdbc42.jar to work, because we are having JDBC Connectivity issue and the solution might be to upgrade to sqljdbc42. Please see Option 1 in this link:
https://blogs.msdn.microsoft.com/dataaccesstechnologies/2016/11/30/intermittent-jdbc-connectivity-issue-the-driver-could-not-establish-a-secure-connection-to-sql-server-by-using-secure-sockets-layer-ssl-encryption-error-sql-server-returned-an-incomplete-respons/
Of course some of you might say to upgrade Glassfish to a later version but in case is this is not an option, would errors occur? I found out that editing the asenv.bat will do the trick (http://alvinalexander.com/blog/post/java/fixing-glassfish-jdk-path-problem-solved) but I'm not sure about the deeper problems we might face.
Thank you so much for your answers.
You would have to be very brave (and have lots of free time) to try jdk-8 on glassfish-2. While you can still download glassfish-2, the Extended Support support ends this year (2017). This is not even Premium Support, it's Extended meaning you have already gone too far by this time. I know this because of a client I used to work for that used glassfish-2.
There were multiple bugs and complaints reported or the 3-rd and 4-th versions with jdk-8, not even speaking of 2-nd. Unfortunately you should upgrade to something way more recent (and have a constant plan to upgrade from there still). Obviously you can try and change the jdk version and see what happens - but I bet you would be visiting this site way more often than you would want to.
The real reason why you should seriously consider upgrading is that not a lot of people can answer deeper problems we might face, because not a lot of people use this version. Just my 0.02$.
Last year, in 2009 GSoC, I participated with an organization called Winlibre. The basic idea is having a project similar to Aptitude (or Apt-get) and a GUI like Synaptic but for Windows and just to hold (initially), only open source software. The project was just ok, we finished what we considered was a good starting point but unfortunately, due to different occupations of the developers, the project has been idle almost since GSoC finished. Now, I have some energy, time and interest to try to continue this development. The project was divided in 3 parts: A repository server (which i worked on, and which was going to store and serve packages and files), a package creator for developers, and the main app, which is apt-get and its GUI.
I have been thinking about the project, and the first question that came to my mind is.. actually is this project useful for developers and Windows users? Keep in mind that the idea is to solve dependencies problems, and install packages "cleanly". I'm not a Windows developer and just a casual user, so i really don't have a lot of experience on how things are handled there, but as far as I have seen, all installers handle those dependencies. Will windows developers be willing to switch from installers to a packages way of handling installations of Open source Software? Or it's just ok to create packages for already existing installers?
The packages concept is basically the same as .deb or .rpm files.
I still have some other questions, but basically i would like to make sure that it's useful in someway to users and Windows developers, and if developers would find this project interesting. If you have any questions, feedback, suggestions or criticisms, please don't hesitate posting them.
Thanks!!
be sure to research previous efforts on this. Google turns up several similar/relevant efforts.
http://en.wikipedia.org/wiki/Package_management_system#Microsoft_Windows
http://windows-get.sourceforge.net
http://pina.plasmite.com
IIRC there was an rpm for windows at some point
Also I think there was some guy (who used to work at MS) in the news recently that basically is starting up a very similar project. I can't find a link to this now.
But anyway, yeah, it would be awesome if there was such a standard tool and repository.
I can only speak for myself, but obviously I could definitely make use of such a tool as I found your post through googling! ;)
My two use cases for this tool would the following ones:
1. I generally avoid to re-install my system as long as possible (in fact I manage to do so only for switching to a reasonable (not each an every) new version of Windows every few years or to setup new computers). But still I'd like my software to be up-to-date. Neither do I want to have to go to all the web pages and check manually if there are compatibility issues with the new version of Doxygen, Graphviz and the latest version of MikTeX for example, nor do I want to have to navigate to the download pages and run the setups all by myself. I just want to schedule ONE SINGLE (!) tool, which checks whether there are new updates or not and updates those applications which are not in conflict with any other application version.
If it unavoidably happens to me that I have to re-install my system, I don't want to get the new setups neither (and check compatibility). I even don't want to wait for one setup to finish in order to start the next one, I just want to check the tools I need, or even better, I want to simply load my "WinApt XML" batch installation file, which gets the installers and handles the setups sequentially all by itself.
I don't know enough about the architecture of .deb or .rpm but IMHO the most reasonable would be to maintain a DB with only the names, versions, dependencies and the location of the different versions' download locations. I mean, most of the tools available for Windows provide .msi packages anyways, which (I guess) is the application itself and some custom installation properties (really not sure how scripting is handled, but I know that creating a MSI in Visual Studio has very limited abilities to create custom installation steps and I can only imagine this is due to limitations of MSI protocol).
I guess a GUI will be mandatory for Windows users ;) but I personally would prefer the additional ability to handle the setups with the console.
Well, I like the idea and would love to hear from that (or such a) tool in the future.
Cheers
Check out NSIS. It's an open source MSI creator. You might be able to use it as part of your package creation software.
http://nsis.sourceforge.net/Main_Page
For the ALT-.Net tool/lib stack there have been some affords in this direction: Horn Get
However, the usability in a real world project has been subject in this SO question.
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.
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.