Author: Amit Schreiber

This is a short idea… adware and spyware authors rely on connecting to some of Windows’ (or Internet Explorer’s) services through the Windows Registry. Generally speaking, there’s a DLL somewhere, which is pointed to by a GUID in the registry.

It’s possible to know, from the DLL, which interfaces the classes inside implement and implement their interfaces yourself. Then, by changing the pointing GUID in the registry to a new DLL, which implements the same interfaces, Windows will load your stub DLL (which does nothing, for example) and this will disable the malicious software.

I admit that I didn’t look into it in enough detail to make sure it works, and right now I don’t feel like infesting my computer with crapware (nor am I going to buy virtual PC software) so I’m just wondering if it’s a good idea.

While reading this post about C# 3.0 on MSDN Blogs I thought about an idea to make pluggable compilers. Let me explain:

In every programming language the language designers have to decide which features go into the language and which features stay out. These decisions are crucial to the development of a language and the rate of adoption of it. Once a decision to include a language feature is made, it cannot be undone.

So the idea is to make the compiler pluggable, in the sense that you could include lingual features you’re interested in and exclude others. This could be used to streamline the development style in a team of programmers, for example. In the companies that I have worked for so far, using advanced programming techniques, which were great to use but you had to go through a learning curve to understand, was frowned upon. In production code there’s not always room for creativity at the price of code readability.

A pluggable compiler won’t be easy to make. It will have include a parser, which will know to which compiler plugin it should address when it finds a certain syntax, and different feature syntaxes may interfere with one another. Now I’m wondering if it is even possible to make a plugin-based compiler. Maybe just having the possibility of turning off some language features could be nice. But it’s just an idea.

Previously, I wrote about experimenting with TAPI3. TAPI3 is Microsoft’s implementation of a Telephony API for Windows. One of the new things in TAPI3 (except for being implemented using COM) is that in TAPI3 the abstraction of the API goes beyond phone devices, and also includes H323 (which is a Voice over IP protocol) telephony.

Seeing that I thought to myself that a nice project would be to create a way to use your home computer to make local phone calls over the Internet. For example, let’s say you travel outside your country to a place where there is an Internet connection. The idea was that you would connect to your computer at home, instruct it to dial (using a modem) and talk to a person in your local area.

For a while I thought this idea could even be extended to a peer-to-peer network of people allowing calls to be made using their computers while they are out of their homes. Think about it – a person goes to work and leaves her phone line unused for all that time of the day when she is at work. This line can be used, by people who live far away, to make free calls (assuming local calls are free).

However, today phone rates are dropping as more and more VoIP infrastructures are being established. The relay station idea is no longer such a big motivator for people to use. Maybe the peer-to-peer thing can be implemented with a different technology, which is available today, in an easier way.

I wrote some code to get the MLRS to work. Unfortunately, I had a problem with my computer’s crappy hardware (or at least I think that was the problem), so I stopped developing this one.

Oh, and one more thing… I know that MLRS also stands for Multiple Launch Rocket System. The pun is definitely intended.