Registering .ocx in 64 bit

[TimStone]

I have a file, cipwin32.ocx which I have registered in the executable file directory.

I then make the call:

Code: Select all  Expand view

SetObject := CreateObject("cipwin32.easyIntegrator")
 

When executing the code, I get the following error:

Code: Select all  Expand view

   Error description: Error TOleAuto/-1  REGDB_E_CLASSNOTREG: TOLEAUTO:NEW
   Args:
     [   1] = C   cipwin32.easyIntegrator
     [   2] = U  
     [   3] = U  

Stack Calls
===========
   Called from:  => THROW( 0 )
   Called from: xhb\xhbole.prg => TOLEAUTO:NEW( 0 )
   Called from: xhb\xhbole.prg => CREATEOBJECT( 0 )

 

I used this process in my 32bit builds previously, and the provider told me the same .ocx should be fine in 64 bit.
I did a lot of research on the web for that error code, and it can any number of issues. It is not specific enough.

I have to register it manually for testing. Ultimately my install package will register it.

I'm using Visual Studio 2022, the latest Harbour build, FWH 22.03. Any suggestions or thoughts on this will be greatly appreciated.

[Antonio Linares]

Dear Tim,

I have googled for "cipwin32.ocx" and found this:
https://dev.gravitypayments.com/docs/easy-integrator/

where you can read:

Win32 ActiveX OCX library – “cipwin32.ocx”

If it is a Win32 OCX it won't work on 64 bits, no matter what your provider may have told you as we can't mix 32 and 64 bits code

[TimStone]

Antonio,

Thanks for the response. For my own understanding, many of the files we link into our 64 bit program are labeled as "32" .lib files, and the program works. Is it just not possible to use a 32 bit ocx file with a 64 bit application? Many of those lib files are from Windows, ie. shell32.lib, and many more.

I'm just trying to understand what can, and cannot, be linked into a 64 bit library, and how they are different.

Thank you.

[Antonio Linares]

Dear Tim,

One thing is the names and another the code. Windows uses stuff named 32 but it is 64 bits software.

In this case, if they only provide a single “cipwin32.ocx” and it is the one that you use from your 32 bits app, then forget about using it from 64 bits as it is.

There is no way at all. They must provide a “cipwin64.ocx”.

https://social.msdn.microsoft.com/Forums/en-US/34b76b61-750d-4323-bf2e-13110113d093/use-32bit-activex-control-in-64bit-application?forum=vcgeneral

Just google for "32 bits ocx from 64 bits" and you will find many entries confirming what I am telling you

[TimStone]

Antonio,

I COMPLETELY understand the need for an .ocx for 64 bit from them. I got that with your first response and already asked them for it.

My last question was to understand the use of 32 vs 64 bit .lib files in general, not related to this feature. I get confused because if you look at a windows build with FWH / Harbour for 64 bit, many of the libs are labeled 32, so I was wondering if there is a way to know what works, and what doesn't.

For an example, look at one of your suggested 64 bit builds and you will see files listed that I am referencing.

Again, this is for General knowledge, not specific to the ocx I first cited.

Thank you.

[Antonio Linares]

Dear Tim,

I already told you:

Windows uses stuff named 32 but it is 64 bits software

There are tools to inspect them and check the above. 32 bits and 64 bits can't be mixed, sorry.

[Jimmy]

hi Tim,

you can have same Source for 32 Bit and 64 Bit ... but it depend how you compile it

Code: Select all  Expand view

   #ifndef __64__
      #define FWDESCRIPTION "FiveWin for Harbour"
   #else
      #define FWDESCRIPTION "FiveWin for Harbour 64"
   #endif

but you can not use 32 Bit LIB or DLL with 64 Bit App

as *.OCX is a *.DLL you can (try) to "check" it with this Code ( also work for *.EXE )

Code: Select all  Expand view

#include "Fileio.ch"
#include "HMG.ch"

#define IMAGE_FILE_MACHINE_I386  0x14c
#define IMAGE_FILE_MACHINE_IA64  0x200
#define IMAGE_FILE_MACHINE_AMD64 0x8664
* REQUEST HB_GT_WIN_DEFAULT           // Console

PROCEDURE Main(cDLL)
LOCAL cBuffer, nHandle, nBytes, nPointer
LOCAL cMachineType
LOCAL hHex
LOCAL cText := ""

   IF !FILE(cDLL)
      MSGINFO("Dll Name missing")
      QUIT
   ENDIF

   nHandle  := FOpen( cDLL , FO_READ )
   cBuffer  := Space(512)
   nBytes   := FRead(nHandle, @cBuffer, 512)
   FClose( nHandle )

   nPointer := AT("PE"+CHR(0)+CHR(0),cBuffer)
   IF nPointer > 0
      cMachineType := ( SUBSTR(cBuffer,nPointer+4,2) )

*     hHex := PeekWord(cMachineType)
      hHex := BIN2W(cMachineType)
      DO CASE
         CASE hHex = IMAGE_FILE_MACHINE_I386
            cText := "for 32bit Machine"

         CASE hHex = IMAGE_FILE_MACHINE_IA64 .OR. ;
                   hHex = IMAGE_FILE_MACHINE_AMD64
            cText := "for 64bit Machine"

      OTHERWISE
            cText := "unknown Machine"
      ENDCASE
   ENDIF

   MSGINFO(cText)
RETURN
 

[TimStone]

Thank you Jimmy.

[Antonio Linares]

Dear Tim,

Could you please test this code in both 32 and 64 bits ?

32or64.prg

Code: Select all  Expand view

#include "FiveWin.ch"

function Main()

   local hDLL

   MsgInfo( hDLL := LoadLibrary( “cipwin32.ocx” ) )

   MsgInfo( If( FreeLibrary( hDLL ) != 0, "Properly freed", "can't free it" ) )

return nil

I am curious to know what you get. I just did it with Microsoft user32.dll and to my surprise in both cases I got a valid handle...

[Antonio Linares]

Dear Tim,

Another test that you can do is this one from a command window and check what msg you get:

For 32 bits:
%systemroot%\SysWoW64\regsvr32.exe cipwin32.ocx

For 64 bits:
%systemroot%\System32\regsvr32.exe cipwin32.ocx

Note On a 64-bit version of Windows operating system, there are two versions of the Regsv32.exe file: The 64-bit version is %systemroot%\System32\regsvr32.exe. The 32-bit version is %systemroot%\SysWoW64\regsvr32.exe.