Intel 82852/82855 GM/GME mobile display drivers for 32-bit Vista (x86) (XDDM) and perhaps 32-bit Windows 7 (x86)
Top books January 23, 2010
Winter break at the UW now comes to a close. I was able to get a lot done during the two-and-a-half weeks, and even took breaks for skiing and an evening trip to the Warehouse rock gym in Olympia, but my main project, which was to upgrade DBEdit, ended up taking much longer than expected.
DBEdit is the custom-built editing application for the thai-language.com lexicon. The current version is a C++/Win32 application version that dates back to 2000. It incorporated a statically-linked component called 'DBManager' to manipulate the in-memory database. For many years, the 'reading' half of DBManager's functionality was used by the production website to render webpages as well. At first this was achieved through a COM interface. When Microsoft introduced .NET to the server platform, the DBManager COM object was wrapped with a .NET assembly wrapper. Finally, about two years ago, the database reading functions were rewritten in C#.
However, this fork between the C++ and C# versions--the two shared only a common on-disk file format--caused development to become blocked by parallel code maintenance concerns.
So, my task over the past few weeks was two-fold: First, database writing capability had to be added to the C# code, and second, DBEdit had to use these new routines to manipulate the database. To do so, it would have to use the mixed-mode feature of the C++/CLI language. Mixed-mode allows a program to include both native C++ and managed C# code. This was important because DBEdit has thousands of lines of user-interface code that would take too long to rewrite.
Ripping DBManager out of DBEdit was easy. I created empty stub functions in the header file, and made sure that the program still compiled. That's where I stood an hour into the project, not knowing there would be a few hundred to go. Perhaps a clue should have been that there the header file of empty stub functions was 3700 lines long. Next, I used Visual Studio code analysis features to eliminate functions that were not needed. To the remaining stubs, I added a C++ 'throw' statement, and began a tedious cycle of running DBEdit, to see where it would halt, telling me what the "next" function I had to port over was.
Pretty quickly, I had the first screen up, using the managed C# back-end. However, booting the program to that point did not require any database writing, and I had already known that the reading part of the managed code worked. However, having gotten the program to boot and prove the concept of my mixed-mode vision, I now started to move away from the idea of keeping all my changes coralled in the stub file: I now felt comfortable with abandoning the ability to compile DBEdit the old way, and I started putting managed C++/CLI code directly in DBEdit.
As I mentioned, it may have taken as much as 300 hours to finish the job. I had to be extra paranoid with the database writing code, since bad code here would introduce corruption into the database, possibly ruining my website's most valuable asset. Testing the new version is now ongoing and my assistant in Phuket, David, has been invaluable in this.