Information Engineer

Even working for Microsoft and looking in Windows source code did not helped my to understand the deep mystery of Windows software updates.

In my primitive software developer mind software is just a chunk of code: say binary file (may be text file, but hey!).
Naturally, code has version.

say…

code_v1

code_v2

code_v3

It is loaded in memory and runs. End of story.

Now… we can make libraries if we want to invite evil into our lives ( DLL HELL!!!) so s/w became

code_v1 + dll_v1

code_v2 + dll_v2

code_v3+ dll_v3

It is still works the same.

Now … we have more than one s/w or for some reason DLL version out of sync with s/w. That is still fine, as long we know what version works with what version

codeA_v1 + dll_v1

codeA_v2 + dll_v1

codeA_v3+ dll_v2

codeB_v1 + dll_v2

codeB_v2 + dll_v3

codeB_v3+ dll_v3

As you see, there is still no problem. We may have more files, but it is still “all peachy”. We can just copy to install. We can even “optimize”

\common
\v1\dll_v1
\v2\dll_v2
\v3\dll_v3
\copmanyA
\v1\codeA_v1
\v2\codeA_v2
\v3\codeA_v3
\companyB\
\v1\codeB_v1
\v2\codeB_v2
\v3\codeB_v3

Now, you can run any version of s/w if you like and it still works. Right?

Now. we can have Documents or Data Base. This is more tricky. We may move data format UP.

If this is the case, V+1 s/w should be able to convert or will have to start from scratch.
Obviously, new and old files should be kept separately, renamed or replaced ( say just a new file ).

New s/w should be careful not to “kill” old s/w files: apparently from same company it may be easily done.

Now, s/w can communicate!

codeA_vX codeB_vY

they both may need to know:

1) where to find a peer
2) API

Both tasks looks trivial.

1) We can use registry
2) We work only with API of certain version.

This is END of STORY.

It does not matter if we use COM or DLL or some other way of communication.

We can still pretty much just copy files and update a few configuration files to upgrade s/w.
Old s/w can be similarly deleted if needed.

The trickiest part is to document files and one need to be smart with design.

Same about API: changes produce a need to upgrade s/w that works with yours.

Can it be done on system level?

Sure!

Say windows. We do not need run XP in VM on Win7. We do not need to worry about compatibility.

We need multiple DLLs. Just like WINE do it. It may be better than VM. More effective, especially that “core” of Windows is still the same, so it is mainly redirection and not double code.

Only “new” code moves to SYSTEM_V_X.DLL -> SYSTEM_V_Y.DLL. Old code a redirected if needed.

So, if your s/w was linked for SYSTEM_V_XP_1.DLL it will work on Win7 as long as this DLL is there ( and correctly implemented by Microsoft)

Well, it is not all that easy when CORE of OS fundamentally changed, but it can be done for USER mode DLL’s, I believe. Just like MFC.DLL had versions Why not all OS?

Now, as long as Microsoft keep doing a good work and keep comparability in this USER MODE DLL’s as kind of “virtualization” it all should work. Just work.

While Drivers can be USER MODE ( as say MINIX OS try to prove) and handled similarly. Today Windows OS Core is not suitable for that ( ha ha , I know ) So, drivers, may need to be re-written. Tough luck!

But … I do not care. What I want is when I buy a new Win7 Laptop, my Photoshop IS STILL WORKING.

End of story.

So, what the puzzle you ask? Well… Why Microsoft OWN s/w have BIG TROUBLE to install on it OWN OS or do upgrade?

Ex: after Office 2003 installed “compatibility tool” Office 2007 REFUSED to install till I clean and wipe it all clean. Why?

There are many examples. Also, when s/w needs some other s/w from the same company and it is free, it should be able just to fetch and copy it to it proper location without making any trouble.

Now… the last thing: BREAKING CHANGES. Once in a while company need to patch a hole. Say API_A_A_A
does some bad thing. It can not be “fixed” : if your code use it: after fix you are broken. What can be done?

Well… first, update should say just that second, it is posable to find who use this DLL. ( linking info) and let user know what applications can be broken ( even potentially).

Last, it will be nice if VS would make a “report file” that can be send to Microsoft when product is released. That should be in DB. Say:

name: My Company
e-mail: xxx@myCompany.com
product:MyCodeA
use:DLL1_a ( API 1 API 2 …. or *)

When ( BEFORE) Microsoft release a breaking changes it should automatically notify “My Company” and let me react. It will be super nice if MS would offer update for my product AT THE SAME TIME as breaking changes.

It all should be voluntarily :

1) User should be give choice : get security fix and have PHotoshop broken or wait
2) Adobe should be able to “ship” “fix” with MS update to make user both “safe and happy” In this case notification will say: We will update your Photoshop as well ( may be via just redirect or calling Adobe Auto Update – does not matter )

This all sounds simple and oversimplified of course, but apparently … it is not done this way.

Microsoft update is not working with speed of X-Copy and Adobe was not in rush to provide Vista Compatible Photoshop, that despite it is a user mode nature just CRASHED.

Yeah … I know there are a compatibility labs. MS is trying to approach this from other direction

But for me this is still a huge mystery…

I want to see install by copy and I want to see new version happily run next to old one.

My Mac does that So I know it can be done

In some respect Win7 will be similar to my OS X system: we both will have XP runing in VM Now… that IS funny!