I was just reading an article about the new U.S. Energy Bill that intends to extend Daylight Savings Time an additional month (starting in 2007). I wonder what the impact of this is on the Computer Science front. There has not been any chatter on my normally read blogs, but perhaps there will be soon. I have no facts to back up my theory here, but lets play along with my conspiracy theory and possibly learn something about static and dynamic linking of DLLs.
Think about this from the Microsoft C/C++ developer perspective: the date functions are implemented in the C standard library, MSVCRT.DLL (or its post VC6 brethren MSVC*.dll). Lets assume (although I am guessing) that the "rules" for the current daylight savings time are implemented in this same DLL (NOTE: Please see comments). One of these functions is called mktime(). Let me quote from MSDN:
When specifying a tm structure time, set the tm_isdst field to 0 to indicate that standard time is in effect, or to a value greater than 0 to indicate that daylight savings time is in effect, or to a value less than zero to have the C run-time library code compute whether standard time or daylight savings time is in effect. (The C run-time library assumes the United States's rules for implementing the calculation of Daylight Saving Time).So if we developers assumed that the runtime would take care of conversions for us, and we statically linked to the library, we may have to recompile against a newer link library (with the revised code) for our applications to continue working if this change actually happens. On the other hand, had the developer dynamically linked to this DLL and not copied the pre-dst-updated MSVCRT.DLL to the application folder or application current directory (Remember that in Windows Server 2003 and possibly Windows XP the rules have changed), the DLL can be updated once in the system32 directory (perhaps through Windows Update) and our preexisting applications will be none the wiser and work just fine with the change.
This is more food for thought on the debate of static vs. dynamic linking that could help sway some developers into a different line of thought - I prefer dynamic linking, but in some cases for some applications I do not practice what I preach. For the installation folks, please read the previous link (and the comments - good stuff there on merge modules) - this is why you need to be sure that you are following proper version replacement and marking shared DLL's as shared - otherwise you can cause grief for other applications or your own.
[UPDATE: 10/4/2005 - fix formatting and errant character]
View my LinkedIn profile
4 comments:
There are parts of Indiana that have chosen not to be involved with daylight savings time. So at certain times of the year you can cross a county line and be an hour different, and other times when you are at the same time when you cross the line. Friends that I have in the area have missed appointments because of this. I hear legislation may be changing this next year. So with freaky things like this going on does it really matter??
I understand that Indiana is a bit weird with DST - that has to be tough living in the surrounding areas. The true impact of this change is based on what the application is suppossed to do, and how the application does it.
There were really two points I want people to recall related to this post - (none of which are DST):
1) Foster thinking of why you may want to use dynamic linking instead of static linking.
2) Understanding DLL load order and its impact on deploying dynamically linked projects.
As a side note, I'd like to see what the anticipated cost savings of the DST extension measure is...
Steve asked me to add a comment here. I'm the development lead of the Visual C++ Libraries team.
My strong recommendation is to use dynamic linking whereever possible. There are three reasons for this
1) Servicing
Generally, when Microsoft services Visual Studio DLLs, it only provides them to developers. We leave it up to developers to decide when their customers need these fixes based on the specific needs of their application.
However, in an emergency (such as an active internet worm), we may need to service centrally. We've not had a situation like this yet in the VC Libraries, but it can happen.
If you've taken our redistributable static libs and linked them into your code, there's no way we can help you out. You'll need to service all your own binaries built this way.
If you've used our DLLs, we may be able to service ourselves. This would be difficult-but-possible with our earlier versions, but with VC8 running on Windows XP and later, it becomes much easier as we've used manifest based deployment.
2) Smaller footprint -- both in memory and on disk. Improves performance, reduces various costs. Plus, reduced runtime cost, as each static CRT requires its own heap, globals, etc.
3) Simpler model -- state is shared, so that the locale need only be set once, for example.
Feel free to contact me if you have questions.
Martyn
martynl@microsoft.com
I forgot to say one thing. We are looking at the DST issue right now and trying to understand the right response. In most cases the CRT gets its daylight savings settings from the operating system, however, and so we'll also need to work with them to understand the impact.
Martyn
Post a Comment