Driver Station Update fails to install

[Crossle86]

I suspected as much. I just couldn't believe anyone would implement a program version in such a ridiculous manner.

Ok, yes I copied the program and that explains the version.

I observed strange behavior with this update on my backup DS and now on my competition DS I have seen the same thing:

After install of update 1, I had two DS programs in the C:\program files\FRC Driver Station directory:
Driver Station.exe (this is the old version)
DriverStation.exe (this is the new version) if i run this program, I see the new version 09021500 as expected.

Since the Driver user would only launch Driver Station.exe, I decided I would rename Driver Station.exe to Driver Station-old.exe and rename DriverStation.exe to Driver Station.exe. This would make the Driver user launch the updated DS program.

However, after the rename (and a reboot), the Driver Station.exe is the old version. Seems impossible but it has happened on two systems. Driver Station.exe and Driver Station-old.exe are the same. I can't explain this and it seems impossible but there it is.

So, prior to all this, I had made a backup copy of the driver station directory. I went into the backup directory, did the same renames and then copied the renamed Driver Station.exe (now the updated version) to the real directory (thats how I got 03051500) and low and behold this time Driver Station.exe runs as the updated version and the Driver user runs the updated version.

I would say all this is insane of I had not seen it happen twice on different systems...

[jhersh]

Originally Posted by Greg McKaskle

Also, small correction, it is the new version without the space. The builds of these tools were modified to be more automated, and spaces_and_command_lines_do_not_get_along.

It's actually gnu make and spaces that didn't get along well and instigated the change.

Originally Posted by Alan Anderson

The format of the version ID is "DDMMYY00", and it shows the date of the .exe file.

That is only true of the old DS. The 2015 version and later implements it in a more sane way (baked into the EXE).

[jhersh]

Originally Posted by Crossle86

I suspected as much. I just couldn't believe anyone would implement a program version in such a ridiculous manner.

Agreed. I changed it this year when I had the opportunity.

Originally Posted by Crossle86

However, after the rename (and a reboot), the Driver Station.exe is the old version. Seems impossible but it has happened on two systems. Driver Station.exe and Driver Station-old.exe are the same. I can't explain this and it seems impossible but there it is.

I would say all this is insane if I had not seen it happen twice on different systems...

I tend to agree. No idea what may be happening to copy the old DS over the new one. The only thought I have is an "Install repair" of the old DS installer, but you didn't mention doing any such thing.

[Crossle86]

I have been busy with other things for some days now but am back to this problem now. The last reply indicated the 2015 DS does not use the file date as part of its version number...but on my systems this is still happening. The key thing that I am seeing and may explain some of what I have been struggling with is this (which I am looking at on my DS PC right now):

I have two program files:
Driver Station.exe (renamed from DriverStation.exe, believed to be the current vesion)
Driver Station-upd-0.exe (renamed old version)

Now these two programs are both exactly the same size and both programs show the windows properties version of 15.0.0.49156. Yet when I run these programs I get different version numbers displayed:
Driver Station.exe = 05031500
Driver Station-upd-2015-0.exe = 20121300

How is this possible? One thought that keeps recurring is that I have used the wrong installer for the current version, but I followed the links on the current software version web page and installed from there...and version ending in 1500 is identified as the current version...so?

Also note that if the installer is installing a changed program name, Driver Station.exe -> DriverStation.exe, it is not updating the shell registry key that starts the DS program as the Driver users shell to reflect that change. That key still has Driver Station.exe as the alternate shell.

[jhersh]

Originally Posted by Crossle86

I have been busy with other things for some days now but am back to this problem now. The last reply indicated the 2015 DS does not use the file date as part of its version number...but on my systems this is still happening. The key thing that I am seeing and may explain some of what I have been struggling with is this (which I am looking at on my DS PC right now):

I have two program files:
Driver Station.exe (renamed from DriverStation.exe, believed to be the current vesion)
Driver Station-upd-0.exe (renamed old version)

Now these two programs are both exactly the same size and both programs show the windows properties version of 15.0.0.49156. Yet when I run these programs I get different version numbers displayed:
Driver Station.exe = 05031500
Driver Station-upd-2015-0.exe = 20121300

How is this possible? One thought that keeps recurring is that I have used the wrong installer for the current version, but I followed the links on the current software version web page and installed from there...and version ending in 1500 is identified as the current version...so?

Also note that if the installer is installing a changed program name, Driver Station.exe -> DriverStation.exe, it is not updating the shell registry key that starts the DS program as the Driver users shell to reflect that change. That key still has Driver Station.exe as the alternate shell.

I just tested with a recent build of the driver station by "touch"ing the executable and the version reported on the title bar did not change, and neither did the version on the diagnostics tab. Inspecting the code it appears that only the title bar version is the hard-coded version I added. The diagnostics tab uses the Creation Date of the executable, so a touch is not going to change it since that affects the Modification Date. Perhaps what you are attempting changes the Creation Date.

This clearly needs more improvement in the future.

[Crossle86]

An update. I just did a repair of the NI install as was suggested. After repair there is a "new" program (different than the two mentioned in the last post) called DriverStation.exe. This is what we would expect. However, it is interesting to note it is the same size as the other two but the windows version is 15.0.0.49159. When I run this program it displays version 09021500. This is what we expect for the update. I then renamed it to driver station.exe and ran it again and it displayed 09021500. Switched to Driver user and the DS runs there and displays 09021500.

This all appears to be correct and what I expected on day 1 of this adventure. Program with 15.0.0.49156 would seem to be old version and 15.0.0.49159 would seem to be updated version and the version displayed by the 49159 exe seems to confirm that. We want version ending in 1500.

However, I still have a program file with windows v 15.0.0.49156 that displays its version number as 05031500. This does not seem to make sense, but the fact that this happens would seem to be a major factor in the confusion I have had.

Things seem headed in the right direction. Now to do this fix on our competition DS and see if all good there.

[Crossle86]

Joe,
Just read your post. I am an experienced Windows developer and I also showed the DS program to another one of our mentors, who happens to be a Microsoft employee and a lead on the Windows team. Some observations:

1) I caused the create date of the DS program to change by copying it, which I did while trying to figure out why I was not getting the updated program when I renamed driverstation.exe to driver station.exe. Still no explanation for that but I am willing to drop it since I seem to have the updated program in place now.

2) Windows programs should always use a hard coded version or version based on the internal assignment of the 4 part windows version number, major.minor.build.fix or as I like to do major.minor.fix.build. If you use visual studio, all this can be managed automatically and your program can display the version embedded in the exe. If you are using LabView, then you have to manage the hard coded version yourself.

3) This version should be displayed in the application title bar though many developers leave off the build in the title bar. The title bar version and the version displayed by the app should not be of different forms.

4) Using file dates is not at all a good idea since the user can "change" the program version number.

5) Don't forget about the Driver user shell program not getting renamed. After a successful install of the update, the Driver user still runs the old program (hence the renaming I am doing). Note that I could have tweaked the registry to the correct program name, but I have our DS PCs set up to allow switching between the 2015 and 2014 DS programs as we still run last years robots quite a bit for demos and having the DS program name the same facilitates this switching. I know the 2015 is supposed to let you switch protocols, but this did seem to work when we first installed 2015 so we did it ourselves. And doing it ourselves allows us to switch out the custom display program we have for the upper part of the DS display.

Sorry if I am stating the obvious but I felt bound to mention all this due to the time I have spent on this version numbering issue.

Thanks for responding to my posts.

[jhersh]

Originally Posted by Crossle86

However, I still have a program file with windows v 15.0.0.49156 that displays its version number as 05031500. This does not seem to make sense, but the fact that this happens would seem to be a major factor in the confusion I have had.

As I stated in my last post, the value shown there is the Windows Creation Date of the file, so if you did something that changed that, it would have this effect.

[Crossle86]

Joe,
Just read your post. I am an experienced Windows developer and I also showed the DS program to another one of our mentors, who happens to be a Microsoft employee and a lead on the Windows team. Some observations:

1) I caused the create date of the DS program to change by copying it, which I did while trying to figure out why I was not getting the updated program when I renamed driverstation.exe to driver station.exe. Still no explanation for that but I am willing to drop it since I seem to have the updated program in place now.

2) Windows programs should always use a hard coded version or version based on the internal assignment of the 4 part windows version number, major.minor.build.fix or as I like to do major.minor.fix.build. If you use visual studio, all this can be managed automatically and your program can display the version embedded in the exe. If you are using LabView, then you have to manage the hard coded version yourself.

3) This version should be displayed in the application title bar though many developers leave off the build in the title bar. The title bar version and the version displayed by the app should not be of different forms.

4) Using file dates is not at all a good idea since the user can "change" the program version number.

5) Don't forget about the Driver user shell program not getting renamed. After a successful install of the update, the Driver user still runs the old program (hence the renaming I am doing). Note that I could have tweaked the registry to the correct program name, but I have our DS PCs set up to allow switching between the 2015 and 2014 DS programs as we still run last years robots quite a bit for demos and having the DS program name the same facilitates this switching. I know the 2015 is supposed to let you switch protocols, but this did seem to work when we first installed 2015 so we did it ourselves. And doing it ourselves allows us to switch out the custom display program we have for the upper part of the DS display.

Sorry if I am stating the obvious but I felt bound to mention all this due to the time I have spent on this version numbering issue.

Thanks for responding to my posts.

[Crossle86]

Originally Posted by jhersh

As I stated in my last post, the value shown there is the Windows Creation Date of the file, so if you did something that changed that, it would have this effect.

Just to clarify, I was referring to the 1500 part of the version as I get the create date part of the version number. I thought it odd that two programs with the 49156 build would display 1300 and 1500 as the last 4 digits of the version. Is this odd or are you saying changing the create date has an effect on the last 4 digits as well as the first 4?

[jhersh]

Originally Posted by Alan Anderson

I'm not from NI, but I think I can help you understand. The format of the version ID is "DDMMYY00", and it shows the date of the .exe file. When the installer puts the file on your computer, Windows adjusts its date and time to reflect the current time zone. You'll see numbers representing February 8 or 9 based on how far east of Austin you are.

If you're seeing 05031500, something apparently modified the .exe file today. That's not normal.

This is mostly correct, except that it is the Creation Date not the Modification Date.

Originally Posted by Crossle86

Just to clarify, I was referring to the 1500 part of the version as I get the create date part of the version number. I thought it odd that two programs with the 49156 build would display 1300 and 1500 as the last 4 digits of the version. Is this odd or are you saying changing the create date has an effect on the last 4 digits as well as the first 4?

I would expect the first 6 digits to change.

[Crossle86]

Ah...yes. I did not read carefully and thought it was just the first 4 related to create date and the last part was actually hard coded. Reading more carefully explains a lot.

[jhersh]

Originally Posted by Crossle86

1) I caused the create date of the DS program to change by copying it, which I did while trying to figure out why I was not getting the updated program when I renamed driverstation.exe to driver station.exe. Still no explanation for that but I am willing to drop it since I seem to have the updated program in place now.

It makes sense that the creation date would change if you copied it.

I can't imagine what you were seeing either. Maybe a strange Windows installer thing? No idea.

Originally Posted by Crossle86

2) Windows programs should always use a hard coded version or version based on the internal assignment of the 4 part windows version number, major.minor.build.fix or as I like to do major.minor.fix.build. If you use visual studio, all this can be managed automatically and your program can display the version embedded in the exe. If you are using LabView, then you have to manage the hard coded version yourself.

Sure. I agree. The versions we generate in our build system have the form major.minor.updatePHASEbuild. E.g. "15.0.0f7".

This is the form I intend to have used in all utilities, however the display in the title bar will be the abbreviated version. There is a set of rules for abbreviating that we use. You may notice that the DS title bar shows "15.0". That's what the above build version is abbreviated to.

Originally Posted by Crossle86

3) This version should be displayed in the application title bar though many developers leave off the build in the title bar. The title bar version and the version displayed by the app should not be of different forms.

I agree that there should not be 2 different versions. The version generated by our build system is adapted to the Windows File Version that you were looking at in the properties. That 15.0.0.49159 is the same as 15.0.0f7. If you convert the 49159 to hex, you'll see it is 0xC007. The 2 most-significant bits indicate the phase. Options are d, a, b, f for development, alpha, beta, final respectively. The 14 least-significant bits are the build number.

Originally Posted by Crossle86

4) Using file dates is not at all a good idea since the user can "change" the program version number.

As stated, I attempted to fix that, but didn't change it in both places. My bad.

Originally Posted by Crossle86

5) Don't forget about the Driver user shell program not getting renamed. After a successful install of the update, the Driver user still runs the old program (hence the renaming I am doing). Note that I could have tweaked the registry to the correct program name, but I have our DS PCs set up to allow switching between the 2015 and 2014 DS programs as we still run last years robots quite a bit for demos and having the DS program name the same facilitates this switching. I know the 2015 is supposed to let you switch protocols, but this did seem to work when we first installed 2015 so we did it ourselves. And doing it ourselves allows us to switch out the custom display program we have for the upper part of the DS display.

I've reported this to our installer person.

[Crossle86]

Originally Posted by jhersh

It makes sense that the creation date would change if you copied it.

I can't imagine what you were seeing either. Maybe a strange Windows installer thing? No idea.

I think I may have confused all this by having a very incorrect view of the version number although I did see a case where running the installer did not place driverstation.exe on the PC. Enough has happened here I will just wear this one as me getting confused.

Originally Posted by jhersh

Sure. I agree. The versions we generate in our build system have the form major.minor.updatePHASEbuild. E.g. "15.0.0f7".

This is the form I intend to have used in all utilities, however the display in the title bar will be the abbreviated version. There is a set of rules for abbreviating that we use. You may notice that the DS title bar shows "15.0". That's what the above build version is abbreviated to.

Seems that abbreviated version does not communicate anything useful if the last part does not change when the version of the program changes. ie, if 15.0 is the first ver of 2015, then update 1 should be 15.1 for the title bar display to have any value.

Originally Posted by jhersh

I agree that there should not be 2 different versions. The version generated by our build system is adapted to the Windows File Version that you were looking at in the properties. That 15.0.0.49159 is the same as 15.0.0f7. If you convert the 49159 to hex, you'll see it is 0xC007. The 2 most-significant bits indicate the phase. Options are d, a, b, f for development, alpha, beta, final respectively. The 14 least-significant bits are the build number.

I'm not getting this completely. The C007 2 most significant bits are 11 or 3. How does that relate to the option letters (index?) or is the f truncated when converted to windows 16 bit version component?

Thanks for this info.

[jhersh]

Originally Posted by Crossle86

Seems that abbreviated version does not communicate anything useful if the last part does not change when the version of the program changes. ie, if 15.0 is the first ver of 2015, then update 1 should be 15.1 for the title bar display to have any value.

Actually it should have been 15.0.1 in the title bar, but due to my not paying attention to when a colleague was planning to upload the update, I had not yet bumped the version number, so the update accidentally went out as a higher build number of update 0 instead of how it should have gone out, which is as update 1. Any following update will be 15.0.2.

Originally Posted by Crossle86

I'm not getting this completely. The C007 2 most significant bits are 11 or 3. How does that relate to the option letters (index?) or is the f truncated when converted to windows 16 bit version component?

The 2 msb are an enum. Sorry I didn't make that more clear. With 'final' being the fourth entry in the enum, its value is 3.