Bug Vanquisher

27 April 2007

Runtime Code Generation in C++ 3

Filed under: C++ — Tanveer Badar @ 9:40 PM

[Update 27/04/2007, this post has been overdue for almost two weeks now.]

As I promised that I’ll be discussing Function and its descendants in this post, here are the tiniest little details about them. A Function represents a free standing, translation unit level function. It has a name, a return type, a set of parameters, an optional exception specification, a possible function level try block, and most importantly, a set of statements. These details also apply to all of its descendants, with a few exceptions. A function can be inline and can have template parameters in its declaration.

Public interface for a function is fairly simple and most functions are either get/set style or return a reference/pointer to some internal representation detail. The real fun resides with the protected interface to the class. It begins with the call to writetext. This function first writes out all the template parameters if any using writetemplateattributes. Then, if the function is declared inline, inline is written to the output stream. Then, if there is a return type specified, first its declarator is written followed by its declarator specifier (omitting the name of variable). Next, we write the name of function. This function is virtual because constructors and destructors do not have separate names. After writing the name, we move on to the parameter list and write it using writeparameters. This function calls writeasparameters for each parameter in VariableDeclaration collection. Now, it is time to write exception specifications if any using writeexceptionspecs. This function first checks whether the target compiler supports exceptions specifications and if the result is false does nothing, otherwise, writes every type name in the given list. Next, we write try for function level try block after checking the result of FunctionTryBlock. This function returns true only in the case if the target compiler supports function level try blocks and this function has associated catch clauses. With everything done, it is time to write the body of function using writebody. writebody iterates through all the statements and writes them one at a time. Finally, if FunctionTryBlock returned true earlier, we write the associated catch clauses.

This discussion left one important piece of functionality away. The need to write a function declaration in header files and in class definitions. We do this with the help of writedeclaration which calls the virtual function declaration. This function writes all the template parameter, the return type if any, declarations of all parameters and exception specifications if any.

Next important class is the MemberFunction. A MemberFunction represents a class member function. A separate class is necessary because it has a set of attributes like static, virtual, const, volatile, pure and accessibility. Some of these are mutually exclusive or imply others, like a static function cannot be virtual, const or volatile; a pure function implies virtual; virtual excludes any template parameters. All the dirty work is handled in get/set functions for its attributes and writetext works almost like that for a function, with the additional work of writing template parameters of its parent class and writing attributes like static, virtual, const, volatile and = 0 where applicable. declaration also works similarly and inserts additional information where necessary.

Constructor represents a class’s constructor. It has two additional attributes. Get/set functions for explicit and a list for constructor initializers. writetext does the extra work of writing explicit before inline if necessary and writing constructor initializers right before writing the body of constructor. declaration changes to accommodate the facts that a constructor has no return type and has the same name as its parent class.

A Destructor has two additional attributes apart from those of Function for representing its virtual and pure properties. Its writetext is very simple and only writes the template parameters of parent class, name, exception specifications, function level try block and body of destructor. declaration is even simpler, it write template parameters for parent class, name and exception specifications.

Finally, we consider syntactic sugar, Operator and MemberOperator. An Operator is just a function with the changes that it does not have a name; its name returns the textual representation of the operator it overloads and has one additional attribute that returns the operator type. It does not override writetext or declaration because overriding Name does the job. A MemberOperator derives from Operator and adds additional attributes just like MemberFunction does to Function, with the noted exception that a member operator cannot be declared static. writetext and declaration for MemberOperator work just like for Operator except that it adds the template parameters of parent class before anything else.

Type‘s family is already squeaking in my ears to go out to public.

Advertisements

26 April 2007

Windows Search in Windows Vista

Filed under: Windows Vista — Tanveer Badar @ 4:29 PM

Where to begin? Searching in Windows has always been a laugh. When tired of working, press Win + F and see that abomination of an animation, the dog. Failing to find results; continuing search even after pressing Stop; window not closing instantly; slow performance. The list goes on and on. Then, there was another beauty hidden behind the scenes. The indexing service [aka. cisvc/cidaemon]. Though it performed very well when uninterrupted and indexed whatever you threw at it. It had one major problem. Index rebuilds. Whenever power failed, on the next startup, indexing service threw away everything and started from scratch. Before I installed a UPS at home, I would have manually searched for a document rather than rely on indexing service/built-in search to do the job.

Windows Desktop Search tried to address most of these issues. It found everything and much more, performance was really fast, really reading from an index instead of going to every file and folder. No more behind the scene searches. But it had this big problem, not supporting full query language like indexing service did. You had to restrict yourself to just one boolean operator at a time. There was no way to compose another search out of some preexisting ones. Another big issue is if you lose power, you lose the index sometimes. It starts building from scratch upon next boot.

Windows Search in Windows Vista seems to finally overcome this final obstacle, although it does not integrate that well with general file types. Most thoroughly supported files are from Office 2007 suite. You can do things like query composition, apply any number of boolean operators in a query, save a search, do post query filtering by many attributes like name, type, size, author, categories, tags, created/modified dates etc.

Windows Search still has some missing functionality, the result of dropping out of WinFS from Windows Vista. It cannot relate user data yet. Support for attaching arbitrary meta-data to any file or folder is missing. That’s where Office 2007 suite shines most because it natively supports meta-data properties like author, title, subject, comments, categories, tags etc. You can also use most of these with pictures but that’s it.

Until WinFS ships at whatever stage of my life, I will gladly embrace it. I am way too much addicted to searching on meta-data, attaching arbitrary properties, setting authors, keywords, categories, tags on documents.

As a work around I am working on something.

23 April 2007

Finally some XPS in native C++

Filed under: C++ — Tanveer Badar @ 2:16 PM

I just read this and haven’t checked it myself. Use with care and beware of security vulnerabilities in zlib.

Deep drive into WPF graphics internals Part 1

Filed under: WPF — Tanveer Badar @ 12:28 PM

[I cannot make up my mind how to best start this post. Instead of delaying it for another month, I opted to post it anyway. <warning>Take it with a pound of salt, I may be terribly wrong in this article.</warning>]

A few pictures from MSDN should be the best start. They show the interaction between Win32 provided API, DirectX and WPF.

  1. How WPF leverages Windows Platform

  2. The Visual tree

  3. How WPF draws your application.

These articles are mainly focused on graphics implementation in PresentationFramework, PresentationCore and WindowsBase. The unmanaged part will discuss milcore.dll, dwm.exe, dwmapi.exe, user32.dll’s redirection APIs.

To dig into all of this, we need a working application. This code will be used through out this post.

using System;
using System.Windows;

namespace WPF
{
     class App : Window
     {
         [STAThread]
        public static void Main( )
        {
            ( new Application( ) ).Run( new App( ) );
        }

         protected override void OnRender( System.Windows.Media.DrawingContext drawingContext )
        {
            System.Diagnostics.StackTrace st = new System.Diagnostics.StackTrace( System.Threading.Thread.CurrentThread , true );
             Console.WriteLine( st.ToString( ) );
            base.OnRender( drawingContext );
         }
     }
}

As the name suggest, OnRender is the only method called to do all the drawing. A debug tip shows that it is really an object of type System.Windows.Media.VisualDrawingContext.

Fire up Reflector and have a look at this class:

As we see VisualDrawingContext does not contain many things. _ownerVisual is any Visual having an associated VisualDrawingContext and CloseCore just calls RenderClose on the contained Visual. DrawingContext is the base class which defines the characteristics of what can be drawn and how. DispatcherObject is of no concern here, but in the going, it is essentially a wrapper around System.Threading.Thread and provides some services which check whether, through VerifyAccess and CheckAccess, the caller is on same thread as UI thread or not.

Furthermore, DrawingContext is abstract, therefore, an instance can never be created. RenderDataDrawingContext has an internal constructor. Same goes for its instance too. A transitive closure with the help of Reflector shows that there is no other way to create an instance publically without going through RenderOpen, which returns an instance of VisualDrawingContext.

You may have noticed by now that I skipped RenderDataDrawingContext’s description. Well that’s the topic for next post.

21 April 2007

Getting dirtier with Visual Studio Orcas (Update)

Filed under: Orcas — Tanveer Badar @ 6:24 PM

An update to my tantrum is coming in a day or two. Stay tuned.

19 April 2007

The two horns of Longhorn

Filed under: Fun — Tanveer Badar @ 11:24 AM

Just read this off Tim Sneath‘s blog.

18 April 2007

Getting dirtier with Visual Studio Orcas

Filed under: Bugz, Orcas — Tanveer Badar @ 2:20 PM

Aha! I forgot about one bug I encountered in the setup. It installed VSTO for Office 2003. I never had Office 2003 installed on it. The version of Office installed on my machine is Office 2007. Setup went ahead to install its VSTO version for Office 2003 and latter on complained that some functionality (actually most) will not work unless I installed Office 2003.

The question is: I didn’t have the right version in the first place, why install something that will not be supported? It should have detected the correct version.

Start getting dirty with Visual Studio Orcas

Filed under: Bugz, C++, Orcas — Tanveer Badar @ 11:42 AM

I got my hands on VS Orcas March CTP yesterday and tried compiling CPlusPlusCodeProvider on which I have been working for five years. The code has compiled and worked flawlessly on all previous versions of VC++ [VC++ .Net to VC++ 2005], but now the new compiler reports an error on assignments lines involving auto_ptr objects.

Whenever I have tried to do <object> = new <type>( *other.<member> );, this new compiler whines. Compiler gives error about ambiguous assignment operators. Says it cannot choose between std::auto_ptr< Inner >::operator = ( const std::auto_ptr< Inner >& ) and std::auto_ptr_ref< Inner >::operator = ( const std::auto_ptr_ref< Inner >& ).

When I looked at the source for auto_ptr none of the classes had assignment operators defined, so the compiler is generating the default implementations. However, they both have a public constructor declared like this auto_ptr( T* ptr ) and auto_ptr_ref( T* ptr ).

I don’t remember if these converting constructors should cause any ambiguity. Converting constructor for auto_ptr is more qualified than auto_ptr_ref. It should be the one that handles this conversion, instead of creating any ambiguity.

As I remember the standard, you cannot create an instance of auto_ptr_ref directly, therefore, this constructor should not be declared public but protected. If declared public, it should have been declared explicit in the first place. Moreover, in the library shipping with VC++ 2005, auto_ptr does not derive from auto_ptr_ref. It has just a converting constructor.

I know VC++ team does not write the libraries themselves, instead it is Dinkumware that should be blamed, if it is really incorrect code.

14 April 2007

A facility turning a foul: Day 2

Filed under: Decontamination — Tanveer Badar @ 8:18 PM

Yesterday, I wrote about how a stupid message is causing chain SMS in even stupider customers. Now, it seems people are coming up with all sorts of funny explanations which lack the elegance of educated nature.

I received a SMS telling me that the sender heard it from his close friend that he talked to two eye witnesses of that phone call death. Quite a short chain of trust, don’t you think? Only four hops to the victim! Would you believe that I heard from my second cousin’s uncle who heard it from his friend that he worked with an eye witness who saw aliens landing in Mexico? It’s the same sort of junk. When I pointed it to him, his story changed and he said he heard it from top RF and Telecom engineers.

Human ears are only capable of hearing from frequencies 20 Hz up to 20-22 kHz. Exact values are different for individuals but these ranges have the most consensus. Infrasonic can only be felt but don’t have enough energy to cause any damage. Ultrasonic bounce off various body structures very badly, not imparting much energy during the process. In terms of power (or loudness) we can endure up to 90 dB easily and sounds between 90 dB and 120 dB damage hairs inside inner ear and about 120 dB, all bets are off. No mobile phone can emit even 90 dB during a call which is the level of noise when a jet engine passes overhead. I am not talking about souped up MP3 players which happen to include cellular functionality just by incident. Land lines clip the frequency of captured voice to 4 kHz, the reason your modem cannot go about 64 Kbps. Cell phone have even worst reception and transmission. Note that it is the carrier that is limiting the frequency not the device, this filtering happens in telephone exchanges over which you have no control. Even if you heard 90 dB from a source over which you had total control, you would shut it in a matter of seconds. It annoys that much! Below that level, there is no permanent damage. Therefore, I reject the theory of some voice causing damage.

Turning to the other agent the mobile carrier. I don’t have precise data about the frequency ranges used in transmission and receiving, but it isn’t enough to cause damage to anything in such a short time period. It is claimed that the caller is bypassing all these filters, but cell phones also have embedded decoders and prefilters which reject everything above a cutoff frequency in the range 4 kHz to 8 kHz. There is no way such an ultra hi-fi (pun intended) frequency could damage neurons or hair cells inside ears. These days, we work in an environment immersed in wireless traffic. Talk about cell phones, garage door openers, TV remote controls, cordless phones, IR file transfer among mobile devices, blue tooth, wireless USB, wireless LANs, IR connected devices, WI-Fi, microwaves, radios, satellite communication, microwave background, RFID chips, speed guns for traffic police, advanced burglar alarms and many more. If cell phones are danger to human health some of these things have a much higher potential for causing death than cell phones. If you are so much concerned about it, use a closed user group, a white list for outgoing calls and another white list for incoming calls.

A facility turning a foul

Filed under: Fun — Tanveer Badar @ 1:23 AM

Yesterday, sitting with a bunch of programmers in my team, most of us received a ridiculous message/variants over a period of three or four hours. It said that if you get a call from a certain number you will die because of the frequency used for transmission or the frequency of voice issued from the speaker damaged your neurons. The number mentioned was of course bogus.

We chatted about trying it with land line, one sent a message to that number to see what would happened. All that happened was a response from the carrier provider that that particular message could not be delivered.

I immediately thought that someone was trying to shoot Ring 3. This gave me the idea to invent some of my own hoaxes. I sent the message:

“If you receive any SMS from [my own number], you will die within a week.

Stupid, this message was sent from my number, use your own number when forwarding it to others.”

Older Posts »

Blog at WordPress.com.