Archive for September, 2009

Compiling Firebird on Windows 7 64-bit

Tuesday, September 29th, 2009

Just one more aggravation on the road to 64-bit paradise.  I tried to compile Firebird on my Windows 7 64-bit system using Visual Studio 8, by following the directions given in firebird2\doc\  Of course it didn’t work.  make_icu.bat reported all targets skipped.  Oh joy!

I turns out, if you want to build Firebird using the 32-bit compiler (which I did) on 64-bit Windows, you need to do so from a 32-bit command prompt.  I didn’t even know that there was such a thing, but there is.  The only way I could find to start a 32-bit command prompt was to browse to \Windows\SysWOW64 and start the cmd.exe found there.

Once I tried the build from the 32-bit command prompt, everything worked just like it should have.

More Odd Things About Windows 7 64-bit

Friday, September 18th, 2009

It seems that Microsoft just can’t find enough ways to drive you crazy by moving things around.

If you are running 32-bit applications on 64-bit Windows (and who isn’t) you need to be aware that \Windows\System32 is only for 64-bit applications.  All references to System32 made by 32-bit applications are re-directed to \Windows\SysWOW64.  Therefore, all of your 32-bit DLLs need to be placed into SysWOW64 and your 64-bit DLLs go into System32.  Confusing isn’t it.

But we aren’t done yet.  There is a special area in the registry for 32-bit applications as well.  HKEY_LOCAL_MACHINE\SOFTWARE is only accessible to 64-bit applications.  All references to this registry key made by 32-bit applications are re-directed to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node.

No wonder I get headaches.  :(

Cannot Open Type Library Errors in Delphi5 on Windows7

Thursday, September 17th, 2009

Yet another gotcha with Windows7 and older applications.  I was trying to compile one of my ActiveX controls with Delphi5 on my new Windows7 machine and the link was failing with “Cannot open file: myapp.tlb” errors.  It turns out that if Delphi5 doesn’t have write access to the directory where it is installed it won’t work.  Since the security on Windows7 is much tighter than previous versions of Windows the Program Files\Borland\Delphi5 directory was write protected.  Granting “full control” to everyone solved the problem, at the risk of slightly decreased security.

Manually Registering COM Dlls in Windows 7 (Error 0×80004005)

Tuesday, September 15th, 2009

If you ever need to manually register a COM or Activex Dll in Windows 7 using regsvr32 you will probably get an error 0×80004005.  Microsoft doesn’t bother to actually tell you what this error means but it turns out that it just means that you don’t have sufficient privilege to execute the command.  All you need to do right click on the command prompt link in the start menu and select “Run as administrator”.  Then issue the regsvr32 command from the privileged command prompt and all will be well.

Running TurboPower ProActivate on 64-bit Windows

Tuesday, September 15th, 2009

I have been using the old TurboPower ProActivate product to license my software for years.  TurboPower went out of business years ago but that wasn’t important because the software just kept working.  Well time advances and I am finally migrating my development workstation from 32-bit Windows XP to 64-bit Windows 7.  Lo and behold, when I try to install ProActivate on the new workstation, I find out that the installer (setup.exe) is a 16-bit program, which cannot run on a 64-bit OS.  What to do?

It turns out that all I needed to do what this:

  1. Copy \Program Files\TurboPower\ProActivate to the new workstation.
  2. Copy appobj.dll and licobj.dll from \windows\system32 on the old workstation to \windows\syswow64 on the new workstation.
  3. Use regsvr32 to register appobj.dll and licobj.dll on the new workstation.
  4. Copy the TurboPower\ProActivate folder from the start menu on the old workstation to the start menu on the new workstation.

Et, voila.  Everything works!

Dodged a bullet there. :)

Location of All Users Desktop in Windows7

Monday, September 14th, 2009

Microsoft just loves to move things from one release of Windows to the next.  I wasted another half hour trying to find the All Users desktop.  You will find one in C:\Users\All Users but that is not the one that you can update.  If you try you will get the infamous “Access is Denied” error.  The modifiable one is in C:\Users\Public.  Don’t ask me why, it just is.

New Location for Start Menu in Windows7

Monday, September 14th, 2009

I spent a frustrating half hour or so trying to manually add something to my “Start” menu on my new Windows7 system.  I was trying to add it under C:\Users\All Users\Start Menu.  I was getting “Access is Denied” errors if I so much as tried to expand the directory tree.  It turns out that the actual location of the Start menu has been moved.  The All Users Start menu is now located in C:\ProgramData\Microsoft\Windows\Start Menu and the user specific Start menus are in C:\Users\AppData\Roaming\Microsoft\Windows\Start Menu.  You can manipulate these directory trees to your hearts contents.

Updating Protected Files in Windows7

Monday, September 14th, 2009

If you try to update a file that Windows7 considers to be “protected”, like the hosts file, you will get an “Access Denied” error when you try to save it.  The way around this is to run the program required to update the file as administrator.  For example, you might use notepad to update the hosts file.  To run notepad as administrator, click the “Start” button and enter notepad in the search field.  Right click on notepad and select “Run as administrator”.  Then just make your changes and save the file as you normally would.