"Class not registered" for 64-bit Win 7

[DNAunion]

1) The error VFP reports is as follows:
"OLE error code 0x800040154: Class not registered".


2) The setup
My work computer is a single physical machine running 64-bit Windows 7: however, it has a virtual PC running 32-bit Windows XP too. The VFP code works on the WinXP virtual machine but not on the Win7 machine itself.

Also, although it probably doesn't matter at all, I use Remote Desktop to connect to my work computer.


3) The VFP code is as follows:

LOCAL pBIDM AS LONG
LOCAL strPrinterName AS STRING
LOCAL frmBlackIceDevMode AS FORM

frmBlackIceDevMode = CREATEOBJECT("FORM")
frmBlackIceDevMode.ADDOBJECT("oBlackIceDevMode", "OleControl", "BLACKICEDEVMODE.BlackIceDEVMODECtrl.1")
strPrinterName = "JusticeTrax Imaging"
pBIDM = frmBlackIceDevMode.oBlackIceDevMode.LoadBlackIceDEVMODE(strPrinterName)

The line that throws the error - when run on the Win7 machine itself, but not when run on the virtual WinXP machine - is the ADDOBJECT() call.


4) Solution is simple, right?
The straightforward solution to a "Class Not Registered" error is to register the class. I have done so:

C:\Windows\System32>regsvr32.exe "<path and .ocx file name>"

and I receive a success message when I do. But the problem remains.


5) Class is registered
The class is registered: that is, I can find it in the Registry. Also, I may be wronb but I believe that if a truly unregistered class were referenced that the error would be "Invalid class string" instead.


6) Other
For Windows 7, only a (signed) 64-bit printer driver can be installed. I have no option of sticking with a 32-bit printer driver so that everything is 32-bit throughout. But VFP is 32-bit and so can only load 32-bit apps into its process space.

Are printer drivers loaded in process? I don't think so: I believe a 32-bit printer call from a 32-bit object in the process is emitted towared the kernel, and in a 64-bit environment is intercepted and redirected/changed to a 64-bit call to the 64-bit printer driver inside the kernel.

 

[Olaf Doschke]

If you do register the way you do the class will not be registered correctly in Vista or Win7, UAC might have put the registry entries in the virtualized of the regsitry and if you inspect it you find the entreis as expected, still they are not in the place to be.

Plan in some hours or even a day to learn about the highered security concepts and virtualisation of directories and registry in Windows since Vista.

You can register an OCX or COM dll with regsvr32 by putting that line you execute from the command prompt into a cmd file, right click on it and execute as Administrator from the context menu. That's needed, even if you are Administrator or user of the administrator group. The reason is highered security, processes started by admin users by default don't run with admin privileges, even not adminstrative system tools like regsvr32.exe

Also, as this still is the same exe as from several windows versions before it has no info embedded (manifest), saying it needs admin privileges and so you don't get a promt asking to allow or deny the call, like you see when starting a setup in Vista or Win7.

Bye, Olaf.

Bye, Olaf.

 

[DNAunion]

Thanks for the response.

I had used an elevated command prompt (Run As Administrator) to register the OCX originally, and now putting the command into a .bat or a .cmd file and executing it with Run As Adminstrator gave the same result: a success message but in VFP on Win7 the same error: "Class Not Registered".

 

[Olaf Doschke]

You may have some dependencies of the OCX of some other files, eg DLLs.

To which Blackice product does this belong to and isn'T there a setup for it?

It also may be a license issue, the OCX only working with a proper license key.

Bye, Olaf.

 

[SnyAc]

We have discovered that in Windows 7 installation that is controlled by a domain you have to be logged on as the 'Domain Administrator' in order to register activex controls.



Andy Snyder
SnyAc Software Services

http://www.snysoft.com

Hyperware Inc. a division of AmTech Software

http://www.hyperwareinc.com

 

[DNAunion]

I CANNOT BE THIS EASY!!!

It looks like it was as simple as getting the 64-bit Black Ice printer drivers.

VFP is 32-bit and was already using the correct 32-bit Black Ice OCX (it cannot use the 64-bit one, which is the one I was trying to use and register). The problem was that 64-bit Windows cannot use 32-bit printer drivers. Once I changed things so that my Win7 machine had only the following:
a. 64-bit Black Ice printer drivers
b. 32-bit Black Ice RTK (which includes the 32-bit OCX)
I launched VFP and ran the application: the code that had been bombing due to the Black Ice OLE Control worked fine.

So no changes need to be made to VFP.


Although VFP needs no changes, the installer will. But that's a different matter.

 

[Olaf Doschke]

Yes, why would VFP itself need a change, it's only a matter of the correct OCX registration for the AddObject() to work.

I'll keep in mind that drivers need to be 64bit, I doubt that a bit, there is system32 for 64 bit drivers and OCXes (with the now misleading 32 in it's name just for backward compatibility and there is the WOW32 subsystem for 32 bit drivers, odbc, DLLs, OCXes etc.

Bye, Olaf.

 

[DNAunion]

I meant the VFP code didn't need any change. The other programmer thought that we would need to change the VFP code to test what environment (32-bit or 64-bit) it was running in and create the appropriate OLE object. Something like:

OsBits = GetOsBits()  && UDF that returns either 32 or 64
IF (osBits = 32)
     frmBlackIceDevMode.ADDOBJECT("oBlackIceDevMode", "OleControl", "BLACKICEDEVMODE.BlackIceDEVMODECtrl.1") 
ELSE
     frmBlackIceDevMode.ADDOBJECT("oBlackIceDevMode", "OleControl", "BLACKICEDEVMODE.BlackIceDEVMODECtrl.1.64Bit") 
ENDIF

I was working under that assumption too, but the more I read the more I saw the solution as being much simpler.



All printer drivers in 64-bit Windows have to be 64-bit. At least that is what Black Ice says in one of their Newsletters (emphasis in original) ...

A 32-bit application can run on 64-bit operating systems, but 32-bit printer driver files will not run on 64-bit operating systems. 64-bit operating systems require 64-bit printer driver files.

Therefore, in order for the application to work on 64-bit Win7, I was forced to use the 64-bit version of the Black Ice printer drivers.

I originally figured that since the Black Ice printer drivers I had to use were 64-bit, that I had to use the 64-bit Black OCX too: makes sense, at least superficially.

But VFP is 32-bit and cannot load anything, such as an OLE control, that is 64-bit into its process space. That's why the "Class not registered" error, even though that sounds like it is caused by something else.


When I learned that the Black Ice 32-bit OCX can communicate with the Black Ice 64-bit printer drivers, I uninstalled the 64-bit OCX and installed the 32-bit OCX in its place (and manually registered it), afterwhich everything worked fine.

 

[Olaf Doschke]

I see. Still I did never came across such a branch of using 32 bit or 64 bit OCX depending on OS. 64bit vs 32bit is a decision per process, not per OS.

Only COM Servers embedded in their own EXE run in a seperate process and could be 64 bit even when instanciated from a 32 bit process. OLE separates the reference, which is provided to the caller process (eg a variable oWord in a 32bit VFP process, if talking about MS Word automation) and the real world object (eg the Word Application, which might even be 64 bit in the future). Using the object values and calls are marshalled from one to the other process. I might be wrong that this is such a loose coupling, as it will not limit 32bit processes to 32bit COM servers.

But I'm sure if you talk about a component like an ActiveX control, even if it's not a visible class it will be part of the calling process, so it needs to be the same technology, 32 bit, as a process can't mix 32bit and 64 bit code AFAIK.

Googled about Wow64 again and found:

http://msdn.microsoft.com/en-us/library/aa384274(v=VS.85).aspx

That supports my knowledge. Cite: "These DLLs, along with the 64-bit version of Ntdll.dll, are the only 64-bit binaries that can be loaded into a 32-bit process."

Which in turn means no 64bit OCX or COM DLL can be loaded into a 32bit VFP EXE.

Bye, Olaf.