Should I stick with VBScript?

Sep 4, 2008 at 1:21 AM
Is it important to anyone for me to stay with VBScript as the main engine for the PAL tool? I'm the author of the PAL tool and I'm considering rewriting it in VB.NET or PowerShell. Please let me know your thoughts?
Sep 16, 2008 at 3:02 AM
It's your tool. Don't let us hold you back from taking it where you want it.

The only additional requirement would be to install .Net or Powershell, right? Your typical PAL user probably has one, if not both, already. More importantly, the existence of a prerequisite creates a hurdle. Adding an additional requirement isn't a big deal;  in an environment where one has authority to install LogParser and OWC, it isn't a far stretch to install .Net or PowerShell.

For what it's worth, my vote is VB.Net. I'd be interested in helping with bug fixes and new features once an initial port is complete, if it goes to .Net.

Sep 21, 2008 at 9:51 PM
As Chris said,
"It's your tool" and it's up to you decide the language.
 If you decide to rewrite the code I'm hope it's still remain public: I learn something form your code and I use your technique to parse the status  the indexes inside SQL 2000 to have a visual report ( I can share my code to you if you want: it can be useful an upgrade to SQL 2005  & SQL 2008) .
By the way I' thinking that VB.NET /C# could be a grate improvement. Personally I do not know Powershell at the same levelof  Vbscript or  VB.NET  so I would prefer the VB.NET / C#.

Also my vote is VB.Net.
In any case Also I  would be interested in helping with bug fixes and new features once an initial port is complete.

Sep 21, 2008 at 10:43 PM

Thanks for the feedback. This definetely helps with the decision making.

My concern about making it full VB.NET is that the VB.NET app would need to do a COM interop everytime it queries a datasource such as BLG files. It has to do this because Microsoft Log Parser is the core data access layer and it's a COM application. I haven't tested it yet, but I would suspect that the performance impact of COM interop calls could slow things down. Furthermore, I plan on adding Event Log, IIS Logs, and Event Tracing for Windows (ETW) log analysis to the PAL tool in the next release. I've thought a *lot* about how the tool can process all of these logs at the same time. It is certainly possible, but the unfortunate fact is that it will take a lot of resources to analyze all of these logs at the same time - far more than what it takes to analyze BLG files today.

Currently, I'm the only developer working on the project simply because I enjoy writing it as a hobby. With all of that said, many people like yourselves are offering to help with development with the tool. If we make it pure VB.NET, then development can continue on it as a real open source project.

Tell you what. I'll write up specifications for v2.0 of PAL. Check in the code (something else I need to figure out how it works) of what I have written so far, and go from there.

The ultimate goal of this initiative is really to provide context sensitive information to users about why the computer is slow. The PAL tool is simply a tool that helps with this goal. Many of us share this goal, so together we can create something great for everyone.

Sep 22, 2008 at 2:03 AM
 Hi Clint,
 I know what means programming alone for hobby: for myself I made a little parser that reads and merge multiple kinds of  traces.  I can share it to you  it can help you .

 Ithe tool is able to merge all traces readable by Microsoft Log Parser  , even adding any add-in to read other kind of traces.  I also made some queries that integrate your tool - the XML PAL output I mean -  with mine: in such way I can chech when an appliction fire one of the threasold in relatiuon with the traces that it writes. This applocation is written in C#  on  .NET 2.0
All this words to say : just because you are creating a  "new" one PAL it should be beautiful to make a join between the two application: this should help us on reaching our goal: why the computer is so slow ?
Sep 22, 2008 at 8:22 PM
Hi Clint,

I would vote for using a new platform for it - VBScript is great and those who know it can follow your code, however it is getting a bit long in the tooth. I see Powershell and other programming environments being more efficient and flexible in the long term. I would also really like to see it stay open source - I think that is a great advantage.

Ed Z
Sep 23, 2008 at 6:14 AM
Legally speaking PAL is owned by Microsoft because I have leveraged Microsoft resources in it's development. Luckily, my management sees the value of keeping it open source because it helps everyone in the long run. I'm not sure how long the free ride will last, but I'm making the best of it. As you may have guessed, development on it has slowed because I only work on it when I have free time and I have been very busy lately solving customer performance issues. PAL certainly saves me hours of time every week, but the work never stops. When I can, I try to post my performance analysis adventures to my blog at

I'll do what I can to post specs for PAL v2.0. I'm still new to this "open source" community development, so please be patient with me. Once I get some specs out, I'll start asking for volunteers to help write portions of it. It will be a big project and many of you have offered help. You're time is highly valued by me, so I want to ensure we have some great specs to work from, so your time is used most effectively.

Emanuele74, I haven't ignored you. ;-) Yes, I would love to see the code you wrote to compare XML outputs. This might be something we can leverage as a feature for v2.0. If you have open source development experience, then please let me know how to best merge all of the code.