Archive for November, 2006

Off-topic HP 50G

Tuesday, November 28th, 2006

Finally, the exam period has ended. Now I can return to normal life, reintegrate into the society and why not, write posts. For those who did not know, I’m studying computer engineering at Universidade São Judas Tadeu. Despite my thirty-years-old, I’m still in the third year due to a hectic life that a programmer is suppose to have. I’m sure many of you know exactly what I’m talking about. I had to interrupt my course several times because of lack of money or overwork. Anyway, these past few weeks I was in a rush and I could not compose a decent post. So, you will have to be glad for some funny facts about my new best friend, the HP 50G.

I usually say that a programmer is not a name of a profession, but a name of a disease.”Programmer: A person who suffers for programming”. One of the symptoms that I find most decisive for a programmer their great ability to associate different things with programming, even involuntarily. An example? Easy! When I was studying Industrial Informatics at ETE, there was a teacher who used to speak slowly, about 3 seconds among sentences. He looked like an android. I used to imagine that characteristic was due to the fact the teacher had little RAM, thus took a while to load a new sentence from the HD to be processed by the speech synthesizer. At that time, we said if we had paid attention, we could see a blinking LED in his ear during those breaks. Fortunately, it could be easily solved if there had been a second thread to put the next phrase in RAM as the current phrase was used by the main thread. I do not know what you think about it, but it seems disease for me. :-S

Studying for Computational Numerical Calculus tests and armed with a HP 50G, it was inevitable to program it to automate some steps. The exercises in this subject consist basically of arithmetic, but they are long and full of little rules. Baing a Programming carrier since the age of 13, I have downloaded the manuals and got to work. When an HP is bought, it comes with a “Quick Start” document having 120 pages; but don’t worry, you can download the complete PDF manual having 918 pages in Portuguese.

As it might be expected, I’ve found many sites and tutorials on the subject, even several in Portuguese. The site was a major contributor. On the page about programming you can find a lot of things. And the best thing, it’s all for free.

We can program the HP either in UserRPL or SystemRPL. Programming in SystemRPL gives us a performance gaining of almost 10 times higher than in UserRPL. However, everything in life has a price. The excerpt below was taken from one of the several PDFs I’ve found.

Strange! I could swear I have already read something like that somewhere.

Because I was unable to download a WinDbg version to debug my HP, I decided to program in UserRPL anyway. The language is basically composed of a sequence of keys that were pressed during normal use of the calculator, but we can still use execution blocks, repeating loops (for/while), conditional execution (if, else), sub-programs execution and many other things that I had no patience to read. It’s funny to mix things like IF and ELSE commands that do array operations as if they were as simple as adding one to one.

HP can be programmed on itself, I mean using its own keyboard. But writing on that mini keyboard is similar to play Decathlon on Atari. It works, but you know what will end up happening. Another super uncomfortable thing is trying to understand what is wrong in your program just looking at the source code (which is not indented) on a small LCD screen. One of the facilities is a USB cable that connects the HP to your PC.

To access the stored directories and variables in the calculator, you’ll have to download the software that makes this connection. But if you have an x64 machine (even HP), there will not be drivers available to make this connection. If this is your case, you can use a virtual machine that is running a 32-bit operating system. Wow! That really works!

When connected, it displays a kind of “Explorer” where you can browse the folders and edit variables and programs. With a double-click on the programs, an excellent development environment called “Notepad” opens with its program. Don’t think of indenting your program. When the program is sent to HP, it takes its own indentation, which is not obviously the same as we would like to take.

Well, at least it was interesting to learn more of this. It was really worth spending that money buying something I can program and be able to keep my addiction. But it still does not stop there. If you take a look at the quantity and variety of applications to download from, you will have an idea whatelse it can do besides calculating the matrix determinant. If you’re curious, you can download a calculating emulator on your PC and make a Test Drive.

Kernel + Visual Studio 2005

Thursday, November 16th, 2006

Driver or low-level software developer is used to build their projects on the command line, use text editors like Notepad or Norton Editor to code their drivers. It’s like my friend Thiago says: “Knife in the teeth and blood in the eyes”. Using the command TYPE | MORE to see the compilation error files shows how superior human beings we are, technology dominants who don’t under-utilize our brains, don’t need those superfluous tools like graphical interface with syntax coloring, IntelliSence or even auto-complete. We are at the top of the food chain.

If you really believe that, then it is better you leave this post right here. Today I going to defend the use of tools that help, and much, when a driver is coded and it is needed to deal with functions with large number of parameters and endless structures.

Using or not using the Visual Studio to generate drivers is a kind of discussion that tends to be infinite, such as the use of C++ for Kernel Mode development. On the one hand, there are those ones who argue that the environment is almost never perfectly configured to compile drivers. I’ve read posts from real authorities on the subject by talking about how many days were needed to find a bug that was generated by a compiler optimization or even a bad define that was generated by the Wizard. Those who say that use Visual Studio as development environment requires a minimum knowledge of each parameter used in the call to cl.exe; that the ideal is to use the good old Build that parse files SOURCES, DIR and MAKEFILE and be quite sure about the environment set by the DDK shortcuts is correct. On the other hand, there are those ones who do not give up the convenience of having an integrated environment, the facility just about pressing a key to see the detected error file line , the use of syntax coloring, IntelliSence, auto-complete and many other advantages that Visual Studio offers.

I have been doing this for some time and I remember when the DDK started to bring the compiler embedded into the Windows XP kit. The main purpose of this change in the DDK was a trial to separate the driver development environment from application development environment. This link has already created many problems. The Windows NT 4.0 DDK was based on VC 4.2, but with the arrival of VC 5.0 and later VC 6.0, the symbol table format has been changed and WinDbg stopped working. At that time, I used to utilize SoftIce much more than WinDbg to debug drivers. I continued using the Visual Studio without even noticing this problem. I only had symbol problems when Visual Studio came on version 7.0. The VToolsD does not support the new symbol format yet. Conclusion, I still use VC 6.0 to compile VXDs. Actually, it’s not impossible to use VC 7.0 for this, but we won’t able to debug it.

Later, when we did the upgrade from VS2003 to VS2005, the most drastic changes have turned my life become a little bluer. Since this time, I started using the best of both worlds, that is, the assurance of having a properly configured environment and all the tools convenience that the VS2005 editor could offer.

How can we do it? OK, let’s use the project created in post Getting Started as a starting point. Initially we will need to download the file DDKBUILD.CMD from OSR Online and save it in a directory that would be in your machine PATH. That CMD will need the WNETBASE environment variable configured to the DDK installation base directory. This file is a way to make an external build with Visual Studio. To do this, create a Makefile project in Visual Studio as shown below.

After entering in your new project name folder, where it will be created, just click on “OK”. Even without setting up anything, click “Finish” at the next window. After creating the project, add the files in Solution Explorer. Then edit the project properties as it is shown below. Note that in the “Include Search Path” I’m assuming that DDK installation was performed in the C:\WinDDK\3790. This field has no influence over the compilation process; it just tells IntelliSence which directories should be used to serve as sources for its database.

From this point, we can build the project like a User Mode project. The images below do not require comments. I suppose it’s not necessary saying that drivers cannot be debugged using the Visual Studio environment. Remember that Kernel debugging requires special debuggers for that purpose as I mentioned in my last post.

One particularly interesting window that has been added to Visual Studio 2005 is the “Code Definition Window”, displaying where symbols have been defined as you write them in the code window. See the example when I write a call to IoSetCompletionRoutine.

At last, take a look at the options offered by DDKBUILD. You can list your choices by simply opening a command prompt window and running DDKBUILD without any parameter. Note that we can compile drivers also using the PREfast.

That’s it… Have fun! 😉