Life of a techno-guru
Monday, June 26, 2006
Finding the Most Recently Used Direct3D Application
The Windows registry stores a lot of interesting information, and is home to a lot of settings in Windows. Many people seem to overlook this when looking for information, most likely because it can be very intimidating. Things aren't always as hard to find as you might imagine; Most settings are spelled out in plain english. One interesting piece of information I just found out you can obtain is the most recently used application that utilized the Direct3D API. I'm not exactly sure how this could be useful information, but in the right environment, it might be something you need to know. Anyway, the name of the last executable to initialize the Direct3D API is located in the following registry key: HKEY_CURRENT_USER\Software\Microsoft\Direct3D\MostRecentApplication, and the value's name is Name. For example, my computer is currently set to googleearth.exe because that is the last Direct3D-enabled app I used. Anyway, hopefully someone finds this interesting and useful :) Here's a VB script to grab the value, and if you want to use it, copy/paste the text into a .VBS file and double-click it to run it:
dim appname
set regprov = GetObject("winmgmts:root\default:stdregprov")
regprov.GetStringValue 2147483649, "Software\Microsoft\Direct3D\MostRecentApplication", "Name", appname
wscript.echo appname
¶ 10:38 AM 0 comments
set regprov = GetObject("winmgmts:root\default:stdregprov")
regprov.GetStringValue 2147483649, "Software\Microsoft\Direct3D\MostRecentApplication", "Name", appname
wscript.echo appname
Friday, June 23, 2006
Remote Task Manager
So ... I decided I would post a small HTML application I wrote a little while ago. I've been thinking about how I could improve it, but I don't see much else other than being able to specify a username and password perhaps. I'm sure I could be creative, but that's too much effort :)
Anyway, you're probably itching to know what the HTA does. As you may derive from the title, it is basically a task manager that allows you to view and kill tasks either locally or remotely. Basically, you use it by typing a computer name in the box, and click List Processes. Assuming you are logged on as a user with administrative access to the remote machine (eg. Domain Admin), you'll be able to then view the processes running on the machine, and click the small Kill link beside the respective process to make it go bye-bye. It doesn't really do all that much, but it's still sort of cool. Any comments or recommendations on improvements?
Try it yourself
http://www.filehosting.cc/download.php?id=D32ED46D ¶ 5:42 PM 0 comments
Anyway, you're probably itching to know what the HTA does. As you may derive from the title, it is basically a task manager that allows you to view and kill tasks either locally or remotely. Basically, you use it by typing a computer name in the box, and click List Processes. Assuming you are logged on as a user with administrative access to the remote machine (eg. Domain Admin), you'll be able to then view the processes running on the machine, and click the small Kill link beside the respective process to make it go bye-bye. It doesn't really do all that much, but it's still sort of cool. Any comments or recommendations on improvements?
Try it yourself
http://www.filehosting.cc/download.php?id=D32ED46D ¶ 5:42 PM 0 comments
Thursday, June 15, 2006
Fixing problems with WMI
Sometimes (rarely though) you will have a case where the WMI repository gets corrupted, and when you have a script that attempts to run, you get a Null Exception or something like that. Anyway, that's what I got a couple of times today when I deployed a script that applies a few registry changes using the root\default:StdRegProv class, and I got a couple of reports of it erroring. I didn't initially know any better, but I thought that maybe the StdRegProv class didn't exist in Windows XP SP1 (hence the Null Reference), but that wasn't the case, because it worked on some other SP1 machines. It wasn't until I tried connecting to the root\cimv2 namespace on the couple of affected machines that I understood what was going on; the WMI repository was corrupt. Here's a quick way of testing if there's a problem with WMI:
Refresh the WMI Repository
- Goto Start --> Run ... --> type wbemtest --> hit Enter
- In the Tester utility, press Connect
- Type root\cimv2 in the top-left box where by default it says root\default
- Press Enter
Refresh the WMI Repository
- Goto Start --> Run ... --> type net stop winmgmt --> press enter
- Input Y, if prompted --> press Enter
- Open Windows Explorer ([Windows] + E, keyboard shortcut) and navigate to %WINDIR%\System32\wbem\repository
- Delete all the contents of the wbem\repository folder
- Goto Start --> Run ... --> type net start winmgmt --> press enter
- Goto Start --> Run ... --> type wbemtest --> press enter
- Press the connect button
- Type root\cimv2 in the upper-left box
- Press Enter
Wednesday, June 14, 2006
Microsoft Office 2007 Development
Well, I finally installed the Microsoft Office 2007 beta today. The interface has been change significantly, and I must admit, I had trouble finding the file menu. 
While that may sound quite embarrassing, you'd have to understand that there is no file menu; Instead, Microsoft has replaced it with a shiny Office logo in the upper-left corner of Excel, the first application I played with. The entire toolbar system has been replaced also, with several groups of tasks that you may come across in your usage of Excel. Along the top, there are the following groups: Home, Insert, Page Layout, Formulas, Data, Review, and View.
What I'm more interested in than the UI though, is development around the Microsoft Office object model. Microsoft has kindly provided wrappers for all the various Office components for use in managed code. Since using DllImport to call unmanaged code seems to be somewhat of a pain in .NET, the fact that Microsoft Provided the wrappers is very nice, and hopefully everything will be as straightforward to work with as the Microsoft Office COM interfaces were in Visual Basic 6. Anyway, feel free to grab the Office 2007 beta and give it a whirl! All the managed code libraries are in the root of the install directory, I believe, so load up Visual Studio and start coding! :-) Enjoy! ¶ 10:48 AM 0 comments
While that may sound quite embarrassing, you'd have to understand that there is no file menu; Instead, Microsoft has replaced it with a shiny Office logo in the upper-left corner of Excel, the first application I played with. The entire toolbar system has been replaced also, with several groups of tasks that you may come across in your usage of Excel. Along the top, there are the following groups: Home, Insert, Page Layout, Formulas, Data, Review, and View.What I'm more interested in than the UI though, is development around the Microsoft Office object model. Microsoft has kindly provided wrappers for all the various Office components for use in managed code. Since using DllImport to call unmanaged code seems to be somewhat of a pain in .NET, the fact that Microsoft Provided the wrappers is very nice, and hopefully everything will be as straightforward to work with as the Microsoft Office COM interfaces were in Visual Basic 6. Anyway, feel free to grab the Office 2007 beta and give it a whirl! All the managed code libraries are in the root of the install directory, I believe, so load up Visual Studio and start coding! :-) Enjoy! ¶ 10:48 AM 0 comments
Tuesday, June 13, 2006
First Thoughts on Vista
Well, I'm going to make this brief, but I thought I'd post a couple of comments about Windows Vista. I just got it up and running on VMware, and thankfully I didn't have any problems with the installation. The initial installation of Vista is very nice, and while not by any means quick, it's not ridden with dialog boxes until after all the major stuff is finished; I always hated coming back to a Windows XP install and seeing it waiting for some bit of user input. Anyway, the GUI setup is a breeze, and the initial boot up is pretty normal. A balloon popup warns you of out-of-date definition files for Windows Defender, and of missing anti-virus software, a nice background awaits you, and that's about it. The UI layout really hasn't been changed all that much, which comes as somewhat of a disappointment to me, but I guess you can't change too much between each version of Windows without confusing your entire userbase :-| I did happen across one thing which I'd like to post a screenshot of tonight before I actually do go to bed (I'm wondering if that will ever happen right about now). I came across the Performance Monitor application whilst browsing the System32 folder, and I must say I'm rather impressed. The new layout is well-designed, and it certainly provides a better feel for an overall idea of how your system is running. Also, I took a quick look at the blank MMC console, and it seems that they've done a nice job updating the MMC UI as well. For some reason (and I can't figure out why), the text is easier to read, everything looks a bit more organized, and I feel a bit more in control of what's going on. So anyway, with that ... I'll leave you to make your own assumptions about the rest of the o/s. I'm going to bed now :)
¶ 10:46 PM 0 comments
¶ 10:46 PM 0 comments
Script to find ProgID's Registered with the local COM server
Here's a script I wrote up quickly tonight that grabs all the registered COM objects with ProgID's and outputs it to comma-delimited text. Basically, what I do with it, since I was way too lazy (hey, I had other things going on too :-) to use a Scripting.FileSystemObject is to run it from the command line using cscript.exe and use the ">" to redirect to a file. Here's an example from the command line:
cscript findProgIDs.vbs > progIDs.csv
Then remove the first couple lines from the text document, and open the CSV file with OpenOffice Calc. Select columns A and B, goto Data -->
Sort --> OK, and voila! You now have a list of COM objects, complete with both ProgID and VersionIndependentProgID pulled fresh from your local computer's registry! Now, as for what you can do with these, I have absolutely no idea, but this is at least a start :) Here's what I do: find something that sounds interesting that you'd want to script with (I chose Microsoft.Update.ServiceManager), goto Google, type in the name of the COM object, and see if anyone has examples or documentation on how to use it. Anyway, hopefully this helps someone out or puts some new ideas in someone's mind .... just throwing it out there for fun. You never know what you can find ... maybe even a script that prints out a PDF document without taking the steps of opening it up and choosing print? Until next time ...
EDIT: Here's a link I found to some documentation on using the Windows Update API
on error resume next
subkey = "CLSID"
const HKEY_CLASSES_ROOT = 2147483648
set objWMI = GetObject("winmgmts:root\default:StdRegProv")
objWMI.EnumKey HKEY_CLASSES_ROOT, subkey, keys
for each key in keys
skey = subkey & "\" & key & "\ProgID"
svkey = subkey & "\" & key & "\VersionIndependentProgID"
objWMI.GetStringValue HKEY_CLASSES_ROOT, skey, "", ProgID
objWMI.GetStringValue HKEY_CLASSES_ROOT, svkey, "", IProgID
if ProgID <> "" and IProgID = "" then
wscript.echo ProgID
elseif ProgID <> "" and IProgID <> "" then
wscript.echo ProgID & "," & IProgID
end if
next ¶ 9:18 PM 0 comments
cscript findProgIDs.vbs > progIDs.csv
Then remove the first couple lines from the text document, and open the CSV file with OpenOffice Calc. Select columns A and B, goto Data -->
Sort --> OK, and voila! You now have a list of COM objects, complete with both ProgID and VersionIndependentProgID pulled fresh from your local computer's registry! Now, as for what you can do with these, I have absolutely no idea, but this is at least a start :) Here's what I do: find something that sounds interesting that you'd want to script with (I chose Microsoft.Update.ServiceManager), goto Google, type in the name of the COM object, and see if anyone has examples or documentation on how to use it. Anyway, hopefully this helps someone out or puts some new ideas in someone's mind .... just throwing it out there for fun. You never know what you can find ... maybe even a script that prints out a PDF document without taking the steps of opening it up and choosing print? Until next time ...EDIT: Here's a link I found to some documentation on using the Windows Update API
on error resume next
subkey = "CLSID"
const HKEY_CLASSES_ROOT = 2147483648
set objWMI = GetObject("winmgmts:root\default:StdRegProv")
objWMI.EnumKey HKEY_CLASSES_ROOT, subkey, keys
for each key in keys
skey = subkey & "\" & key & "\ProgID"
svkey = subkey & "\" & key & "\VersionIndependentProgID"
objWMI.GetStringValue HKEY_CLASSES_ROOT, skey, "", ProgID
objWMI.GetStringValue HKEY_CLASSES_ROOT, svkey, "", IProgID
if ProgID <> "" and IProgID = "" then
wscript.echo ProgID
elseif ProgID <> "" and IProgID <> "" then
wscript.echo ProgID & "," & IProgID
end if
next ¶ 9:18 PM 0 comments
Friday, June 09, 2006
Using Oleview.exe to find scriptable COM objects
Hello everyone ... today, I have for you, a quick posting on how to use the Oleview program to locate COM objects that are scriptable in your daily VB scripting! I'm guessing that from the few search results on Google, that not many people are aware of this, but the Windows Resource Kit tools has a handy tool that allows you to view information about the type libraries registered with the COM server on a Windows computer. First, download and install the Windows 2003 resource kit, and then navigate to the folder you installed it to. Open up the oleview executable and browse around in it for a bit if you'd like.
The purpose of using this tool (at least my purpose) is to find some COM objects that I can use with VB script to do cool stuff. One particular object I came across is the Windows Media Player type library. This can be instantiated with the following code:
Now, you might be asking yourself: "What can I do with this object once I've got an instance of it?" That will hopefully come in another article shortly as I'm running out of time, however, I will tell you that you can use Oleview to find out the answer for yourself. Happy scripting! ¶ 11:48 AM 0 comments
The purpose of using this tool (at least my purpose) is to find some COM objects that I can use with VB script to do cool stuff. One particular object I came across is the Windows Media Player type library. This can be instantiated with the following code:
set playerobject = CreateObject("wmplayer.ocx")For beginners out there who are asking "How do you know to use wmplayer.ocx?" I do have an answer! Using the oleview tool, you can figure out the name of the object you would like to create an instance of. If you'd like, follow along by opening up Oleview, and navigating to Objects Classes --> Grouped by Component Category --> Automation Objects --> Windows Media Player, and click that item. In the right-hand pane of Oleview, you'll see some information about the type library, and more specifically, the ProgID (or VersionIndependentProgID) of the object. This is what you need to know in order to create an instance of a COM object. While writing this article, I decided to randomly choose another object in the same list as another example, so go ahead and navigate to Microsoft Agent Control 2.0. Again, on the right side you should see the VersionIndependentProgID of "Agent.Control". By calling the built-in VBscript function CreateObject, you can instantiate this object as well.
Now, you might be asking yourself: "What can I do with this object once I've got an instance of it?" That will hopefully come in another article shortly as I'm running out of time, however, I will tell you that you can use Oleview to find out the answer for yourself. Happy scripting! ¶ 11:48 AM 0 comments
Novell vs Windows login prompt?
Well, I started a new job, and I have been re-introduced to Novell Netware! :-o Anyway, I updated my computer provided to me from Windows XP Service Pack 1 to SP2, and I started having trouble getting the login prompt to show up. I remember having come across this problem almost 2 years ago now, but I thankfully remembered how to get around it. Besides, for whatever reason, it seems that the Novell authentication still works even without using the Novell login box. Well, here's how to fix the problem if you upgrade to XP Service Pack 2 while you've got the Novell client installed:
First, a little background information. Windows XP uses a DLL file called msgina.dll (located in %windir%\system32) to display the login prompt and accept user credentials. When the Netware client is installed, it "takes over your system" by replacing msgina.dll with its own login prompt, appropriately named nwgina.dll. The setting that changes which login prompt is used, is found in the registry under the HKEY_LOCAL_MACHINE hive. If you can't get the Netware login prompt to display after upgrading to SP2, here's a method that worked for me to get around the problem:
First, a little background information. Windows XP uses a DLL file called msgina.dll (located in %windir%\system32) to display the login prompt and accept user credentials. When the Netware client is installed, it "takes over your system" by replacing msgina.dll with its own login prompt, appropriately named nwgina.dll. The setting that changes which login prompt is used, is found in the registry under the HKEY_LOCAL_MACHINE hive. If you can't get the Netware login prompt to display after upgrading to SP2, here's a method that worked for me to get around the problem:
- Boot into Windows XP safe mode by pressing F8 right between POST (Power-on self-test) and Windows XP loading
- Make sure you choose basic safe mode, not safe mode with networking, as this will still attempt to load nwgina.dll
- Login to a local user account with administrative access to the computer
- Choose Start --> Run ... --> type "regedit" and press enter
- Navigate to the following path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon
- Find the GinaDLL value, double-click to change it, and type in "msgina.dll"
- Reboot your computer into normal mode, and login
