Hunting Down a Bogus IP

Posted by admin on January 28, 2010 – 8:04 pm

I was working on a server issue this morning when I ran into something strange. I could no longer access a server that had been running for quite some time without any problems.

I tried a PING and got back an IP address for the server that made no sense at all. It wasn’t even part of my local IP range!

So I did all the normal stuff:

Checked my HOSTS file
ran IPCONFIG /FLUSHDNS
ran IPCONFIG /REGISTERDNS
ran IPCONFIG /RELEASE
then IPCONFIG /RENEW

No joy. A ping was still returning the same bogus address.

So I checked my server’s DNS service. Not even an hit of that address.

Hmmm. So, where the heck was it coming from? A little googling didn’t turn up much, but eventually, I read a blog post that made an offhand mention of WINS.

Now, I don’t really know all that much about WINS. Just never had a reason to, I suppose. Mostly, I’ve always relied on and stuck with plain DNS. But, Ok, I’ll check it.

Go over to my server, and load up the WINS app (it’s under Admin tools)

The left hand window was completely blank. It took a second to realize I had to “query” to retrieve the WINS records, they aren’t automatically just shown.

And AHA! There, in the result list of “Active Registrations” was the bogus address for my server. (I’ve already removed it in the image below, but it was in the highlighted column).

Case closed. I’m still wondering what changed that suddenly, WINS was being used to resolve the server name when it must have not been before. The only thing I can think of is changing internet providers to Verizon FIOS from Time Warner Cable, and the resulting swap out of the main incoming router.

Granted, for a seasoned network guy, this is likely old hat. But for a software dev who only moonlights as a network guy, it might be some useful information!

Getting PHP Up Quick Under IIS 7 and Win7 64

Posted by admin on January 25, 2010 – 3:35 am

Filed under Web

I had a need over the weekend to do a little PHP work. Now, I’m no expert in web anything, most of my time has been spent building nice happy fat client apps <g>. But, when I’ve needed to do a little web tinkering, my host (www.ServerGrid.com) pretty much supports everything, so I’ve just uploaded my files and had at it.

However, this time, I wanted to get things running locally, to avoid all the upload/download hassles.

A few google searches turned up the Microsoft Web Platform Installer.

Wow! Something other than Office, VS and SQLServer that Microsoft has done right!

It took a few minutes to run through, and I had to tweak the PHP.INI file a bit (using the instructions here), but, all told, I had a PHP 5.2 installation fully operational under a local IIS7 server in, oh, 10 minutes.

It the Web Platform Installer can install a lot of other stuff too. CMS, SugarCRM, DasBlog, and a bunch more.

Definitely worth the download!

Merging Assemblies, the Easy Way (part 1)

Posted by admin on January 19, 2010 – 6:54 pm

Filed under Code Garage, Utilities, VB Feng Shui

Recently, I ran into a need to make use of the Mono.Cecil.dll library from a .net application I was working on. Cecil is a fantastic little project under the Mono project that allows you to interrogate an existing .net assembly (EXE or DLL file) and retrieve all kinds of information about the assembly, from the resources embedded within it to the classes and methods defined, and much more. You can even alter the contents of the assembly and write the new version back out to disk!

The thing is, Cecil comes prebuilt as a C# assembly (a DLL file), and I really did not want to have a second file required for this particular application (it’s just a little command line utility).

My first take was to use Oren Eini’s excellent concept of an assembly locator. My idea here was to embed an assembly as a binary resource, then, when requested, read that resource into a stream, load the assembly from the stream, and resolve references to it via the assembly locator.

I’m still working on that concept, because I think it’s a clever and convenient solution to the problem, but, in researching that, I happened to remember the even easier (as in, no code required at all!) solution of using ILMerge.

ILMerge

If you haven’t already discovered it, ILMerge is a Microsoft research project in the form of a single command line EXE utility, that can “merge” any number of .net assemblies with a “target” assembly, and produce either a .net DLL or EXE output file.

There’s a really good article on CodeProject describing the general use of the program. There’s even a GUI (Gilma) for it.

Automating ILMerge

What the article doesn’t go into is automating the ILMerge process. After all, you won’t want to manually run that command line utility every time you build your application!

The good thing is, it’s trivially easy to automate as long as you take care of one critical step.

First, download and install ILMerge from the link above.
Once it’s installed be sure to copy the ILMerge.exe utility to somewhere on your path (or add the folder it’s in to your path).
Then, grab the Mono.Cecil.dll file (or whatever DLL it is you want to merge into your main project EXE). Put it in the root folder of your project.
Go ahead and set a reference to that file, so you still get all the .net intellisense goodness, but be sure to set the Copy Local property for the reference to FALSE (after all, you don’t want to copy this DLL to the output folder along with the application if you don’t actually need it, right?)
With that done, you MAY want to mark the DLL you’re embedding as “included in project” from the Solution Explorer.

If you do this, however, make sure you also set the Copy to Output Folder to “Do not copy” (that’s the default though so it should already be set).

The Tricky Part

One limitation of ILMerge is it that it can’t alter the target assembly “in place”. This means that, for instance, if you want the final resulting executable file name to be called GenerateLineMap (my utility), you can’t have VS compile the assembly to that name. You’ll need to use some other name for the initially compiled assembly.

On the Application tab of the project properties you can change that name, like so:

I just added “-Interim” to the Assembly Name.

Now, go to the compile tab of the project properties and click Build Events

Insert this as the POST BUILD EVENT

ilmerge /target:winexe /out:”$(TargetDir)$(ProjectName)$(TargetExt)” “$(TargetPath)” “$(ProjectDir)Mono.Cecil.dll”

Notice that the OUT parameter specifies the output file name via the $(ProjectName) variable (which is still “GenerateLineMap”) while the first assembly to merge is specified using the $(TargetPath) variable (which is the full filename of the output assembly, including the “-Interim”).

EDIT: Important note: Notice the /target:winexe option. You’ll need to change that as appropriate depending on the type of exe you’re building. In my case, I had a console app where this needed to be set to just /target:exe. Setting it to /target:winexe caused all of the console output functions to just do nothing, which threw me for a bit!

Now, just rebuild the solution and you should see two resulting EXE files in your output folder, one with the “–Interim” (which is the version WITHOUT the embedded Mono.Cecil.DLL file or whatever DLL you’ve chosen) and one WITH the embedded file. As a final cleanup, you may want to add an additional Post build step to remove the “*-Interim” files.

To test, just make sure you DO NOT have the embedded DLL anywhere on the path or in the same folder as the exe and run the exe. If everything went right, your app should work exactly the same as if the embedded DLL was included externally with the app!

Now, your application is back to being a single EXE to distribute, and it was built completely automatically by Visual Studio.

Caveats

You knew there had to be some, right?

The first is that if the dll to embed contains licensing information, it might not work properly after being embedded. I don’t have any DLLs like that to test with, but I’ve read reports about the problem at various sites on the internet. Just something to be aware of.

Second, trying to replace the originally named exe with the newly built one results in VS not being able to debug the exe in the IDE (it throws a message about the assembly manifest being different from what was expected). I haven’t worked that issue out yet. What this means is that you might need to leave any references set to “Copy to Output Folder” while debugging, and not replace the original compiled assembly, just ILMerge it into a new assembly name.

Windows 7 and Vista GodMode

Posted by admin on January 6, 2010 – 5:18 am

Filed under .NET, Vista, Windows 7

If you haven’t already checked it out, definitely head over to Tom’s hardware for their article on setting up “GodMode” in Windows 7 (apparently it works in Vista too, dang, wish I’d known that).

Basically, you create a folder somewhere, then rename it to

GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}

When you do, that folder becomes a “virtual folder” full of (on my system anyway) 278 links to virtually every administrator type function you might ever want to jump to on a Windows Machine. Here’s a sample screenshot:

Very, very cool indeed.

Flipping Video with DirectShow

Posted by admin on December 31, 2009 – 6:11 pm

Filed under .NET, Media, Troubleshooting, VB Feng Shui

If you haven’t checked it out already, DirectShowLib.net is pretty much THE way to get at direct show functionallity in VB.net (that is unless you want to spend $$$). Thing is, it’s only a paper thin wrapper over the DirectShow COM api stuff, so there ain’t no hand holding here.

I’d mucked with it for a while and with the help of some of the sample code, got video playing in a form in VB.net fairly easily, but, I needed to flip and/or rotate that video under some circumstances.

After many googles, I finally came across the IVMRMixingControl9 interface that the VideoMixingRenderer9 exposes, but, no matter what I did, I could not cast from a VMR9 to the MixingControl, like so:

Dim Mixer = DirectCast(VMR9, IVMRMixerControl9)

I kept getting an “Interface not implemented”. Then I happened across a post about a wholly different problem, but buried within it was a comment about needing to set the VMR into “mixing mode” in order for it to implement that IVMRMixingControl9 interface. Ugh! DirectShow is nothing if not interfaces. And odd dynamically implemented interfaces at that. Oh well.

A little more digging, and it turns out to be quite easy. Just obtain the IVMRFilterConfig9 interface from your VMR9 object, and call SetNumberOfStreams on it (with and argument 1 or more).

The end result is code that looks like this (remember, this is with a reference to DirectShowLib.net):

DIM FGM = New FilterGraph
Dim VMR9 As IBaseFilter = New VideoMixingRenderer9

FGM.AddFilter(VMR9, "Video Mixing Renderer 9")
Dim FC As IVMRFilterConfig9 = VMR9
FC.SetRenderingMode(VMR9Mode.Windowed)
FC.SetNumberOfStreams(1)

Dim Mixer = DirectCast(VMR9, IVMRMixerControl9)
Mixer.SetOutputRect(0, New NormalizedRect(1, 1, 0, 0))
Mixer.SetAlpha(0, 0.2)

Note that in this case, the SetOutputRect is reversing the output rectangle, so the video is going to end up flipped and upsidedown, exactly what I was needing. I’ve also set the alphachannel to .2, meaning the video is somewhat transparent.

Unfortunately, there doesn’t appear to be any way to rotate the video using the MixingControl, so that is my next topic of research.

Experienced Developer/Architect

Posted by admin on December 13, 2009 – 11:48 pm

Filed under Uncategorized

Time to move on.

The company I was working for sold several months back. Unfortunately, it was more of a liquidation than a sale, and the buyer already has a pile of developers on staff.

Soooo… I find myself looking for greener pastures (and tasty hay<G> ) once again.

I’ve worked in the commercial software realm for over 20 years, as developer, manager and architect, so I’m well versed in SDLC, and everything from spec development, to coding, testing, beta rollout management, bug tracking, installation development, and versioning.

I’ve written for developer mags like VBProgrammers Journal, and am a co-inventor on 8 patents (numbers 6,678,615, 6,631,326, 6,842,698, 7,142,217, 7,148,898, 7,167,187, 7,190,377 and 7,161,604). I drive for unique solutions to hard problems.

If you’ve got needs in any of the following areas, drop me a message. Maybe I can help.

VB.net (and .net in general)
Legacy VB to .net conversions (VB1 through 6, even the old DOS Basica and PDS, I’ve done ‘em all!)
SQL Server, TSQL, optimization tuning, DB design, etc.
Code porting to .net (I’ve worked with C#, Cobol, and Pascal, but can read just about anything!
Document Management System Integrations (particularly, DocsOpen, Interwoven, and WorldOX, various versions)
Legal and medical software
GIS (Geographic Information Systems)
Office integrations (especially commercial-level addin design and development)
Low level integrations (serial port, networking, that sort of stuff)
Installer building (particularly Wise or InstallShield)
Development management/team leadership
Product design/architecture
Documentation/specifications

Thanks!

That Annoying “The publisher could not be verified” Prompt In Windows 7

Posted by admin on December 10, 2009 – 12:25 am

Filed under Tweaks, Utilities, Vista, Windows 7

I’ve just finished paving my main machine with Windows 7 64 bit, and was working on tidying up some of the finer points of my installation.

One minor item I use is a batch file with a reference to the excellent Poweroff utility. The batch file basically powers down the monitor, locks the machine, then goes into standby/hibernate mode. I attach it to a Ctrl-f11 hotkey to make it a quick keystroke to powerdown my machine.

Anyway, I have that bat on my path, and I happen to keep it out on a network drive (a NAS array), not on my local machine. I generally keep data off my local machine, preferring to only have program installs and temp files locally.

But when I pointed my shortcut to the network path and hit Ctrl-F11, I’d get that annoying “The publisher could not be verified” prompt. Every time!

Well, a few googles later and I came across this tip on annoyances.com.

It’s for Vista, but it also works in Win 7 (even the 64bit version).

Run gpedit.msc 

Go to User Configuration >> Administrative Templates >> Windows Components >> Attachment 
Manager

Add "*.exe; *.bat" to the "Inclusion list for moderate risk file types" setting.

I added *.bat to the list, as well as *.exe because, in my case, I keep a number of handy BAT files in folders out on my network drives and then include those folders in my path.

Works a treat. Be sure to read up on why to include this in the Moderate risk element and not the High Risk, though. Generally, if you have a reasonably good firewall/router, making this change should be safe.

Moving to Windows 7

Posted by admin on December 9, 2009 – 7:00 pm

Filed under Troubleshooting, Windows 7

My system had been getting less and less stable recently, to the point where I’d blue screen and crash the entire machine while just browsing the web in FireFox.

So, when in came up that I’d need to have access to a 64bit OS, I finally decided to pave this machine and lay down a bright and shiny new Windows 7 installation.

Of course, doing so meant a couple of things.

I had to make sure I had my old system available, just in case I needing any config files or whatnot. I keep all my data on a network server so that’s never been an issue. I used wbadmin (the Vista backup utility) to create a full VHD image of my Vista installation to a USB drive for this purpose.
I did not want to wipe out my current raid, even though I had the backup. So I picked up 2 1.5TB Samsung drives to form a new RAID1 array.
My mobo is the Intel Bad Axe 2 (D975xbx2), so it actually has support for the Intel ICH7 Sata raid controller and the Marvell Raid controller. Both can control up to 4 drives, so I figured I’d install the two new drives on the Marvel controller, leaving the existing Intel raid alone for now.

Problem 1

Unfortunately, idea 3 was my first problem. I couldn’t get Win 7 to see the Marvell raid. I spent the better part of a day fiddling with it, before I took the chance and disconnected the drives on the Intel raid. Sure enough, suddenly, the Win 7 installer could now see the Marvell raid.

Problem 2

My joy quickly soured though, when, about 20 minutes into the install, I got a message that the installation was “unable to read installation source files”. That’s it.

Hmm.

Could the CDRom image I burned be bad? Nope: a verify confirmed it was fine.

Maybe the raid array had problems? I reattached my Intel raid, booted Vista, and I could see the Marvell raid drive just fine. I scanned it anyway. Not a single problem.

Maybe I didn’t have the right F6 drivers for the Marvell controller? Some googles turned up that there was in fact, problems with the version of those drivers that Intel makes available, but even the older drivers direct from Marvell resulted in the same error.

Maybe my bios needs an update? Mine was several years old so I pulled the latest and uploaded. Still no dice.

With most of weekend gone, I decided to through a hail mary and try connecting the 2 samsung drives to the Intel raid controller ports. The concern was that, if I disconnected two of the existing raid drives on that controller, would I be able to boot back to the old raid if things still didn’t work? Or would the old raid be toast?

Deep breath, unplug the old, plug in the new, fire up the install, and…

It worked!

Problem 3

Way back, the main issue with 64bit Vista was I had no way to connect to our companies Cisco VPN with it. Well, I still couldn’t find Cisco 64bit drivers, and the 32bit versions won’t install into Win7 64. But, I’d come across the Shrew Soft VPN client before, so I thought I’d give it a shot.

I did need to dig up my Cisco configuration file, but once I found and imported it into Shrew Soft, I was connected first attempt. Pings to servers worked. Connected!

Problem 4

Toolbars. Little thing, granted, but I have run with a toolbar auto hidden on the left, as well as the taskbar at the bottom for ages. It’s comfortable and it put everything I typically use right there.

And Win 7 dropped that feature!

Yep, a feature that’s actually useful and MS drops it. Sigh. In reality, that decision seems to be getting quite a lot of bad blog, so I’m not alone in my sentiments anyway.

Fortunately, a feature in a program I’ve used for quite some time came to the rescue. The program is True Launch Bar from Tordex. I’ve written about TLB before, actually. It’s come in handy for a variety of purposes. For the past few years, when I’ve needed a handy gizmo and thought I’d have to download yet another widget, 9 times out of 10, TLB could already do the job.

This time, I used their “Standalone” version (included with the base package) to duplicate the functionality of the disconnected side toolbar, even though Win7 doesn’t support it directly.

If you like having a highly configured taskbar/toolbar, I (again) highly recommend True Launch Bar. It’s not free, but it’s cheap, and well worth the price.

Taming my Desktop Icons

One last note about my configuration. In the process of setting things up, I came across Fences by Stardock. It’s free. It does one thing, but it does it very well indeed.

Essentially, it allows you to “group” your desktop icons, and they stay in those groups, unlike under normal circumstances, where changing desktop resolution, or other things will tend to scramble your carefully arranged icons quite often.

It actually works on OS’s from Win 7 back to XP. Check it out.

A Minor Incompatibility

I’ve use DiskMapper by MicroLogic for ages. It’s a wonderful way to visualize your disk space usage. Yes, there are similar alternatives out there (like Zero Assumption’s Disk Space Visualizer), but I always seem to come back to DiskMapper.

Well, I tried the install and got an “incompatible application” error. Something about being a 16bit app. Yikes! 16bit!

Well, I pulled my DiskMapper installation files (post install) from the backup image I made, ran the app itself, and, after a quick paste of my registration details, I was up and running. So it would appear that the incompatibility was with the installer and not the app itself. Good news. And another good reason to make sure you have a full backup of your original system before making a switch like this.

And What About Win 7?

I’ve only been using it for a few days, so I’ll reserve some judgment for now. But I will say it feels a bit snappier, plus having the full 4gb ram usable (as opposed to only about 3.4gb under a 32bit os), is definitely a plus.

The ability to mount VHD files directly via the Logical Drive Manager is great. It’s my understanding that you can actually boot the machine into a VHD as well, but I haven’t tried that out yet.

Other than that, it really feels more like Vista SP2 than a really new OS.

VBScript in VB.Net

Posted by admin on November 23, 2009 – 5:31 am

Filed under .NET, ActiveX, Languages, VB Feng Shui

A long (long) time ago, if you wanted your users to be able to enhance your product by add coding logic, you pretty much had two choices:

Dig into Lex and Yacc or….
Roll your own parser and scripting execution engine.

Then, around the time VB 6 was released, Microsoft introduced VBA. It worked, but it was expensive and a god awful complicated mess to integrate with your app, so outside of Microsoft Office (which even as of Office 2010, still supports it!), very few applications actually made use of it.

Around the same time, the Microsoft Scripting Control was released. This was an ActiveX control you could use from any COM compatible language to embed VBScript. Now, of course, this is VBScript, not a “real” language like C or even VB. But, it was free, easy to obtain, and very easy to use.

As the years have rolled by, .NET has steadily grown in capability and while the Windows Scripting Host exe is still shipped with Windows, the old VBScript and JScript scripting has largely been supplanted by either:

ASP and more recently ASP.NET
Powershell
Dynamically compiled .NET code
and likely lots more options I’m not familiar with

Now, all these options are good, and each definitely has it’s place, but, for many purposes, good ol’ VBscript still fits the bit quite nicely.

But can you use it from .NET? And if so, how?

The Tempest in the Teapot

Before I continue, I should point out that any time you start talking about allowing users to add their own code into your application, you’re opening up a huge can of worms that you’ll need to deal with. Things like properly catching exceptions from badly written user code (yeah, that never happens), adding watchdog timers to deal with hung and infinitely looping user code, security concerns, and the like all will have to factor into the decision. You have been warned <g>.

So Simple It Hurts

I had a plugin project recently where I wanted to give the user the ability to write some very simple logic to expand the functionality of the application.

Of course, I wanted to build a full plugin API, but I also wanted to provide a lighter-weight option for those users that didn’t want to dive head-first into a full on .NET project. VBScript seemed like the obvious choice.

A few Google searches later and most everything I found was talking about how to dynamically compile .NET code, which is cool indeed, but not what I was really after. Other articles and posts insisted that users should convert their VBScript code to .NET (ok, yeah, but that’s not really the point now is it?).

Then I did a Google Desktop search of my own system and turned up some VB6 code I’d written ages ago to experiment with the Microsoft Scripting Control.

Now, I know that .NET languages support accessing ActiveX Controls and COM objects in general, but this was pretty old stuff. Would it actually still work?

I cobbled up a dirt simple VB.net project:

Public Sub Main()
    Dim Script = New MSScriptControl.ScriptControl
    Script.Language = "VBScript"
    Script.AddCode("sub Main" & vbCrLf & "MsgBox ""This is a Test"" " & vbCrLf & "End Sub")
    Script.Run("Main")
End Sub

Be sure to add a reference in the VB.net project to the COM object “Microsoft Scripting Control”.

Run it, and lo and behold, I get the “This is a Test” message box, straight from VBScript!

Obviously, there’s lots more to making use of the Scripting Control than just this, but, clearly, VBScript is still very much a choice for adding limited programmable logic to your application.

Creating Good ol’ Standard DLLs with VB.NET

Posted by admin on November 12, 2009 – 3:49 am

Filed under .NET

Managed code (VB.net and C#) are great for a lot of things, but unfortunately, even as of VS2008, it’s still missing at least one. Standard DLL exports.

You see, way back in the olden days, virtually every DLL in Windows was written in C or assembler and exported functions via the standard DLL export table.

Then came COM and now .NET, providing much easier, object oriented export capabilities. Old style EXPORTS have been falling by the wayside ever since.

Unfortunately, if you program for Windows, eventually you’ll find yourself needing to either consume or provide exports. There’s just no way around it.

For consuming (ie simply “calling”) exported functions in a DLL, .net makes that almost trivially easy. All of the Windows API can be called in this way, simply by including the proper attributes (for VB) for the function declaration in your application. Here’s an example for the SENDMESSAGE Windows API function.

<DllImport("user32.dll", SetLastError:=True, CharSet:=CharSet.Auto)> _
Private Shared Function SendMessage(ByVal hWnd As IntPtr, ByVal Msg As UInteger, ByVal wParam As IntPtr, ByVal lParam As IntPtr) As IntPtr
End Function

The Hard Part

However, exporting functions from a .NET DLL in the standard Windows API style is not near as easy.

Why would you need to do this? The main reason is to provide hooks that other applications can call. There are many, many applications out there that require addins or plugins to export standard DLL entry points. Being unable to do this in .net means either having to write a shell in C/C++ around those entry points (doable but cumbersome), or simply not providing that functionality.

The good news is that the .NET compiler designers didn’t completely forget about such down-to-the-metal tidbits as this. The bad news is that they didn’t provide any syntactic sugar to make it straightforward either.

Emilio Reale posted an excellent article on CodeProject that discusses the dirty IL (Intermediate Language in .net speak) mechanics of how to:

compile your .net DLL
disassembly it with ILDASM to IL source code.
find the necessary bits in the disassembled output and what to change them to
reassembly the IL source using ILASM into a DLL with the proper functions exported.

All fine and dandy till you look at what’s required. Needless to say, it’s an amazingly involved process to perform manually.

Fortunately, another CodeProject contributor tackled this problem and posted this article. In it, he presents a small utility and attribute definition dll that allows you to export a function (almost ANY function) from a .NET DLL simply by applying an attribute to it, like so:

<ExportDllAttribute.ExportDll("MyFunction", _
System.Runtime.InteropServices.CallingConvention.Cdecl)> _
Public Shared Sub EntryPoint_MyFunction()
     ...my code goes here....
End Sub

and then running the utility on the compiled DLL, which automates the above tasks.

It takes a little work to get things set up, but in the end, it worked flawlessly for me. Within just a few hours, I’d put together the shell of a plugin for an application that I’d had reservations about writing plugins for, simply because it looked like I’d have to do so in C++.

Now, the whole plugin is done, it’s all in VB.net (my language of preference currently), it’s a single DLL with no dependencies (other than the .net runtime <g>), and it can be deployed by simply copying it into a folder.

Can’t get better than that!