Thursday, February 22, 2007

"I'm neither micro nor soft" - BG's pick up line

How nice of Microsoft's MSDN team to tell us a couple weeks before it happens that there will be a problem with every program we've written, and if we access the registry, our programs won't access the time zone data correctly....great!

This is the email I received from MS today:
"""
Dear Valued Microsoft Customer,

In 2005, the United States government passed the Energy Policy Act of 2005. This act changes the start and end dates for Daylight Saving Time (DST) as of spring 2007. These changes may impact the way applications run. Microsoft is releasing an update for Windows through Microsoft Update that reflects these changes.

Developers who use the .NET Framework may find their applications affected if the application uses the time zone information for historical purposes or if they have derived custom classes from System.TimeZone to provide custom time zone information. The standard System.TimeZone class provides a managed wrapper for the underlying Windows Operating System time zone functions.

In addition, developers who use Visual C++ may find their applications affected if they use the CRT time functions, or the TZ environment variable. Microsoft is currently working on a fix for this issue and will post information about its availability on the Visual Studio Support page.

Most applications that use these affected classes will not need to be modified as this update will ensure that the correct data is provided seamlessly to the application. However, applications that use these classes or the underlying Windows API to perform historical time look-ups will need to be modified.

In most cases, developers who have extended the .NET Framework’s time zone support by creating custom time zone classes derived from System.TimeZone, or by direct access to the Win32 API, will not have to update their applications as long as the available updates to the operating system are applied. However, solutions that rely on private time zone data, or that retrieve system time zone information by accessing the registry directly, may need to be updated. Applications that deal with historical time zone data may also need to be updated.

Microsoft advises all developers who make use of time zone data to test their applications against this update to ensure that their applications function correctly.

For more detailed information and the latest updates please visit http://msdn2.microsoft.com/en-us/vstudio/bb264729.aspx, Preparing for daylight saving time changes in 2007, and KB928388: 2007 time zone update for Microsoft Windows operating systems.

Further Assistance

Microsoft values your business. For more information visit http://www.microsoft.com/dst2007, or contact Microsoft for assistance. A list of phone numbers is located at http://support.microsoft.com. Microsoft Premier Customers may engage their Technical Account Manager directly.

Please DO NOT REPLY to this email as this is not a monitored inbox. If you have questions/inquiries please visit http://www.microsoft.com/dst2007

This e-mail is intended for distribution within the United States. Please contact your local Microsoft subsidiary for similar offerings outside the US.

Thank you,

Microsoft US Developer Team
"""

So, if you're using .NET and System.TimeZone (not derived from though!), or Win32 (like me), you're fine....as long as you have the newest version of Windows Vista 2025 Extra Business First class snakesonaplane Superman3 Robocop Titanium edition. Will they provide an update for Windows 2000 or NT Server? What about 2000 Server edition? What about Windows 98? If not, then all of the code I wrote at my old company can be trashed :)...or at least the time zone functionality.

Well, that's it. I'm glad they told us at least before the fact, and late enough so that no one really freaks out like Y2K (why2fake i called it). Idiots.

This is more of a reason to convince my employers to switch to trusty Linux (I'm using a CentOS box at work for CVS, internet web server, and file sharing via SMB).

Thursday, February 15, 2007

Name and content change

I have a couple "blogs" throughout internetstanbul, and want to consolidate. I kept separate blogs because some of my personal blogs are that post high school emo "woe is me" type bull, which I would rather not have mixed in with programming tips and tricks, or music recommendations, or political discussions.

So what I think I might do is change the name of this blog from "The Science of Programming" to "Sounds, Opinions and Programming", which will include discussions related to the TV show I will be producing and the music related, as well as music I'm into and seeing that's not related to the show. It will include opinions based on discussions, ideas, or inspirations that I get just living life. These will mainly be political in nature, because it seems that most of my emotional energy is driven towards political discussion. Finally, I want to write about programming. I don't just want to write tips, tricks, and new algorithms, but about IDEs, the culture behind programming, compilers/languages, how to manage software and hardware projects, and other things related to my greatest passion, and what I do for a living.

I have absolutely no one yet reading this blog, so I will be surprised if I get feedback on this right now, but I think I should be transitioning within the next few months. Oh, and it will make it easy to search because I'll be labeling each post based on one of three things "programming", "opinion", or "sound"

Tuesday, February 06, 2007

Visual Studio 2005 and "writing" to the registry

I've spent the last few weeks learning how to approach Visual Studio 2005. I have no prior experience with .NET, CLR, managed code, and interop until now. I've been digging through videos, forums, blogs, and newsgroups (mainly through MSDN) to find information relative to my goal. My goal is to make a couple very specific client socket operations in a managed assembly (read: DLL) format. I have to make it part of the global assembly cache, so there are minor requirements to achieve beyond learning the language, libraries, and IDE.

Regardless, there is a lot to learn, and I think Microsoft is heading in a good direction with their C++ compiler group. I also (coming from VS6.0) think the IDE has advanced in many good ways. Least of all of these is the tabs at the top, and the tabbed toolbars on all sides (that you can hide). The only thing I'm worried about, is that M$ will limit what each programmer is allow to use and not use. Yeah, we can use sockets and have access to the registry...but do we really have these things? They're taking away the lowest level of abstraction, in order to provide user friendly tools, so someday they will be able to control every aspect low level access. They will tell us when we can write to the registry, and what and where. I'm not ready for this yet.

This will relate Windows to an OS like Apple IIe... firewalled by hardware. If Microsoft doesn't allow development beyond a certain level, they are essentially fire-walling their OS as if it were impossible to mangle anything below that level. We could, of course, hack the assemblies, but who wants to do that with managed code? With the program memory that will be used in the heap because of .NET libraries, there's a lot of assembly to look through before finding how to hack the registry. We might be getting the best treatment by the Visual Studio C++ compiler and IDE past, but the abstraction and development depths are being sacrificed.

What do you think?