[VB6] Modern Shell Interface Type Library - oleexp.tlb

@ MountainMan,
Thnks ... I was in a hurry and didn't notice that the lOldAddr variable was also declared inside the HookCOMFunction procedure ... Actually I also wrongly left the lpfnAddr variable inside

I have now sucessfully managed to override the CalculateFull Method of the excel application object AND to unhook it back ti its original as shown in the code below :

Code:

---

Private Declare PtrSafe Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" ( _
Destination As Any, _
Source As Any, _
ByVal length As LongPtr _
)

Private Declare PtrSafe Function VirtualProtect Lib "kernel32" _
(ByVal lpAddress As LongPtr, ByVal dwSize As Long, _
ByVal flNewProtect As LongPtr, lpflOldProtect As LongPtr) As Long


Private Const PAGE_EXECUTE_READWRITE As Long = &H40&
Private Const lFuncOffset = 319  'Excel Application.calculateFull Method VTable Offset
Private pVTable As LongPtr
Private bHooked As Boolean
Private lOldAddr As LongPtr
Private lpfnAddr As LongPtr

Sub HookCOMFunction()
    Dim lpVtableHead As LongPtr
    Dim lOldProtect As LongPtr
    Dim pObj As LongPtr
    pObj = CLngPtr(ObjPtr(Application))

    CopyMemory lpVtableHead, ByVal pObj, 8
    lpfnAddr = lpVtableHead + (lFuncOffset) * 8
    CopyMemory lOldAddr, ByVal lpfnAddr, 8

    Call VirtualProtect(lpfnAddr, 8, PAGE_EXECUTE_READWRITE, lOldProtect)
    CopyMemory ByVal lpfnAddr, AddressOf OverrideFunction, 8
    Call VirtualProtect(lpfnAddr, 8, lOldProtect, lOldProtect)
End Sub


Private Function OverrideFunction(ByVal voObjPtr As Long, ByVal Param As Long) As Long
    MsgBox "Excel 'CalculateFull' Method has been Hooked !!"
End Function


Sub Test()
    Application.CalculateFull
End Sub

Sub UnHookComFunction()
    CopyMemory ByVal lpfnAddr, lOldAddr, 8
End Sub

---

Unfortunately, this only works when yielding the CalculateFull Method via code as per the Test Procedure above ... Can this also work when executing the CalculateFull Method via the excel user interface ?!!

Quote:

---

Well in principle, you could subclass the process and intercept the menus WM_COMMAND message, but subclassing a 64-bit app might be challenging.

---

@fefalone,
Thanks ... the whole idea was to replace the VTable address of a given excel Method ( in this case I arbitrarly chose the CalculateFull Method) with that of my own function and override the native Method behaviour

I have successfully done some Subclassing/Windos hooking in office applications before but I am trying to explore VTable redirection and see what I can obtain

Quote:

---

Originally Posted by fafalone

The one problem I've had with this; if you just use the Set statement, and QueryInterface fails (a rare scenario, but one I just encountered*), then you get a Type Mismatch error which would have to go through your error handler or have its own on error resume next statement and then verification that the new object <> nothing. With the QueryInterface method, you can get the HRESULT without an error if it fails, then proceed accordingly.

*The scenario popped up in using IPreviewHandler. To initialize it, an object may implement IInitializeWithFile, IInitializeWithStream, or IInitializeWithItem. Most only implement one of these, and there's no way to know beforehand (or if there is it's so obscure that every example still uses trial and error). There's sure to be other scenarios or true errors in QueryInterface calls.

---

I have not tested this, but according to an example here, determining the interfaces that an object supports can also be done in a more VB-ish manner using TypeOf ... Is:

Code:

---

Select Case True
    Case TypeOf Object Is IInitializeWithFile:
    Case TypeOf Object Is IInitializeWithItem:
    Case TypeOf Object Is IInitializeWithStream:
End Select

---

Good tip, I plugged that into the IPreviewHandler project and it worked.

Code:

---

    hr = CoCreateInstance(tHandler, 0, CLSCTX_INPROC_SERVER Or CLSCTX_LOCAL_SERVER, IID_IPreviewHandler, ipv)
    Select Case True
        Case TypeOf ipv Is IInitializeWithFile: Call MsgBox("IIF")
        Case TypeOf ipv Is IInitializeWithItem: Call MsgBox("III")
        Case TypeOf ipv Is IInitializeWithStream: Call MsgBox("IIS")
    End Select

---

That said, you should know by now that doing things "in a more VB-ish manner" is the exact opposite of what I like to do :D

Using in uuid(00020400-0000-0000-C000-000000000046) the LPWSTR for *rgszNames you can't pass array of strings, so you can't handle named argouments.
.........
LONG GetIDsOfNames(
............
[in] LPWSTR *rgszNames,

you have to replace with

[in] long *rgszNames,

so this is a pointer to one or many names (you can provide the number of these)

I use IDispatch to communicate my Interpreter M2000 with Word using namedarguments.

usage:
ReDim myptr(0 To fixnamearg)
myptr(0) = StrPtr(pstrProcName)
..................so here we pass a strptr
For lngLoop = 1 To fixnamearg
myptr(lngLoop) = StrPtr(pargs2(lngLoop))
Next lngLoop
ReDim varDISPID(0 To fixnamearg)
................... so now we pass the array (beforwe we can't do that)
lngRet = IDsp.GetIDsOfNames(rIid, myptr(0), fixnamearg + 1, cLid, varDISPID(0))
DISPID = varDISPID(0)
End If
(this is code from M2000 Interpreter - is open source)

Yeah in fact I've been thinking about just replacing LPWSTR across the board with longs but have been hesitant since it effects backwards compatibility with code based on olelib. I can change it in the next version coming out in a few days anyway (finishing up Core Audio interfaces)... but in the meantime just out of curiosity; the definition is currently [in] LPWSTR *rgszNames so it's passed ByRef... it doesn't work if you pass pargs2(0), UBound(pargs2) +1 ? This works in most other cases.

New version up containing the full set of DirectShow interfaces-- I really haven't had time to play around with these however so if anyone does, let me know how it goes :afrog:
Also new IMMNotificationClient def is live but whether to adjust similar interfaces is still an open issue. Let me know.

BUG ALERT! If you downloaded oleexp 3.7 before July 16th do not use the olelib2.tlb that came with it without updating. Since olelib2 depends on oleexp3, it has to be recompiled against the new version. So please use the version posted on or after July 16th 2016 of olelib2. Not doing so can cause a **major** bug: all usercontrols and their settings will be deleted from all forms in the project when the form is loaded, and new instances of usercontrols cannot be created, if you have a class module implementing one of the interfaces from olelib2.

Very sorry about that, it's a very obscure and undocumented bug, it took an hour to even figure out that the bug was being caused by the version conflict, as there's no errors on the problem class itself, just the controls disappearing and a 'Error in loading DLL' message when trying to create new controls.

This bug only applies to people who use olelib2 and updated between July 13th, 2016 when v3.7 was posted, and July 16th, 2016 when the fixed version was posted (same version number/filename, oleexp37.zip)
Download the updated versions from the first post or here: Attachment 139493

Hi all,

Is it possible to hook the VTable of an Event Interface such as the ICommandBarButtonEvents of Microsoft Office Object Library ? GUID ="{55F88890-7708-ACEB-C000-006008961DA5}"

Thank you

I think you'd be better off starting a new thread for this. It seems somewhat related to the original question, but not entirely, and there hasn't been any activity for a month. I could split it out for you, if you'd like, but a new thread seems likely to get you better answers.

Quote:

---

Originally Posted by Shaggy Hiker

I think you'd be better off starting a new thread for this. It seems somewhat related to the original question, but not entirely, and there hasn't been any activity for a month. I could split it out for you, if you'd like, but a new thread seems likely to get you better answers.

---

Thanks Shaggy Hiker
I'll start a new thread as suggested

First, thanks for this.

However, there's a rather quirky problem:

Brand new project. Add the reference to the TLB.

Now in your Form Load add the following:

Code:

---

For z = 1 to 2
MSGBOX "Hello"
Next z

---

Try to compile. Good luck - you'll get a compile error about how a variable can't be assigned to this expression. Remove the TLB reference and it compiles fine as it should.

Doesn't matter where the "z" reference is in code. I stumbled across this because I added the TLB to a very large project with lots of code and found that there were NUMEROUS places in my code that used a variable named z. Won't compile with that. Obviously somewhere in the TLB, "z" is being used/defined and the compiler won't allow its use outside of that context.

Wow surprised no one has ever noticed that before; it's a typo from the url.inc file included from the original olelib.tlb this is derived from.

Code:

---

typedef [helpstring("Values for PID_INTSITE_WATCH")]
enum PIDISM {
    [helpstring("Monitor based on global setting")]
    PIDISM_GLOBAL = 0,
    [helpstring("User says watch")]
    PIDISM_WATCH = 1,
    [helpstring("User says don't watch")]
    PIDISM_DONTWATCH = 2,z
} PIDISM;

---

Having 'z' after the comma makes the compiler treat it as the next entry in the enum, so it's a global constant that =3. It's been fixed in the source and will be in the next release sometime in the next week.
In the mean time, note that the only way this bug shows up is if you're using a very bad technique- not declaring your variables. If your project had Dim z As Long, the error would not occur. If you're not up to doing it in every procedure, a slightly less bad alternative would be to add your own Public z As Variant, which is what it's being defined as currently when you haven't specified another type (or if it's always used as a Long, you can declare it publicly as that).

Quote:

---

Originally Posted by fafalone

Having 'z' after the comma makes the compiler treat it as the next entry in the enum, so it's a global constant that =3. It's been fixed in the source and will be in the next release sometime in the next week.
In the mean time, note that the only way this bug shows up is if you're using a very bad technique- not declaring your variables. If your project had Dim z As Long, the error would not occur. If you're not up to doing it in every procedure, a slightly less bad alternative would be to add your own Public z As Variant, which is what it's being defined as currently when you haven't specified another type (or if it's always used as a Long, you can declare it publicly as that).

---

Thanks fafalone! Yes, I'm a bad, bad coder - I frequently don't declare my variables when I use them for simple things like For loops. I know lots of people frown on that, but I don't care - they can frown. :) The very first thing I do when I import anyone else's code is turn off Option Explicit if it's been set. I know all the "real coders" out there are shaking their heads at me but it makes me happy. Option Explicit just irritates the living daylights out of me. :) When the variable type really matters, I declare it. When it doesn't (such as a for loop), I don't. I'm sure back in 1998, the extra overhead between the default variant or a declared int or long mattered more, but even my 100,000+ line program with loads and loads of undeclared vars runs ultra-speedy on even super old hardware with little RAM.

As for your solution, thanks for that - I don't know why I didn't try declaring it public to solve. Anyway, it turns out I didn't have quite as many parts of the code as I thought that used "z" (they were all in For loops), so I just changed them to a different letter. ;) ;)

THIS IS SUPER AWESOME!!!
I can't believe there is still so much enthusiasm about vb6 <3

Quote:

---

Originally Posted by radialapps

THIS IS SUPER AWESOME!!!
I can't believe there is still so much enthusiasm about vb6 <3

---

Well, .NET has a lot going for it and in many respects is a great choice. But VB6, even 18 years later, still has some significant pros compared to .NET and sometimes is arguably the better choice despite what some .NET people think. Unlike .NET, its runtime is included with Windows 2000+ (.NET varies depending on OS) and apps are noticeably speedier/faster to load. There isn't much you can't do in VB6 by using the API. I've got VB6 apps that take advantage of lots of newer stuff/technologies. I do admit that it is starting to get to the point that in order to get VB6 to do what most modern desktop apps need requires LOTS of tweaking and API code, including much that is necessary to replace VB's own limited built-in functions. But once you've done it, then it's relatively straightforward so there are those that have stuck with it over the years and now have code to get VB6 to do lots of the modern stuff a la this posting by fafalone. While I use .NET, VB6 is still my preferred choice in some cases and I think there's plenty of others that feel the same way. There are times that it is the better option even for some new projects IMHO (obviously depending on project type/scope).

Major Project Update!

A huge number of new interfaces have been added as the major version number hits 4.0. I also took the opportunity to ditch the whole 'oleexp3' thing and make the project name version-independent again. Felt this neccessitated a new GUID for the TLB too. So reference must be changed, can't overwrite the .tlb like usual. Last time, swear!

The first sample project with some of the new 4.0 interfaces is up too, and a whole lot more will be coming. Here's the scoop on the new version and the changelog, also found in post #2 (for now).

OLEEXP Version 4.0

---

This is a major version upgrade. Along with a large number of new additions, the TLB itself has changed and a few extra steps are needed. To upgrade existing projects:
-The TLB has a new GUID and as such is essentially a new typelib, with the original name of just oleexp.tlb restored. Remove the reference to oleexp3.tlb and add a new reference to oleexp.tlb.
-Replace all instances of 'oleexp3.<type>' with 'oleexp.<type>. No existing items were modified, so it is safe to run a Replace All with oleexp3 replaced with oleexp
-I promise this is the last time I'll switch the name of the TLB; couldn't stay with 3.x forever and just plain oleexp makes more sense.
-oleexpimp.tlb and mimelib.tlb have been compiled against oleexp 4.0; these can simply be overwritten.
-All sample projects have been updated to use oleexp.tlb 4.0, reference changed and oleexp3. replaced with oleexp. - both attached projects and code in posts.

A large number of additions are geared towards writing highly modernized and sophisticated namespace extensions, there will be a major project along these lines in the future.

(oleexp v4.0 - 24 Nov 2016)
-Added interfaces IThumbnailCache, IThumbnailSettings, and ISharedBitmap. Added coclasses LocalThumbnailCache and SharedBitmap. Added associated enums WTS_FLAGS, WTS_CACHEFLAGS, WTS_CONTEXTFLAGS, and struct WTS_THUMBNAILID.
-Added interface IDefaultExtractIconInit
-Added interface IApplicationDocumentLists with coclass ApplicationDocumentLists
-Added interface IHomeGroup with coclass HomeGroup; added associated enum HOMEGROUPSHARINGCHOICES
-Added interface ITrackShellMenu with coclass TrackShellMenu
-Added interface IContextMenuCB and related structs QCMINFO and DFMICS
-Added interface IExecuteCommand with coclasses ExecuteFolder, ExecuteUnknown, and AppShellVerbHandler
-Added interfaces IExplorerCommand, IEnumExplorerCommand, IExplorerCommandProvider, IExplorerCommandState, IExecuteCommandHost, and IInitializeCommand. Added associated enums EC_HOST_UI_MODE, EXPCMDFLAGS and EXPCMDSTATE.
-Added interface INewWindowManger
-Added interface IDelegateFolder
-Added interface IBrowserFrameOptions
-Added interface IFileIsInUse
-Added interface ICreateObject
-Added interface IShellChangeNotify
-Added interfaces IInitializeWithPropertyStore and IInitializeWithWindow. The latter is Win8+.
-Added coclass ApplicationAssociationRegistration for IApplicationAssociationRegistration
-Added coclass ApplicationAssociationRegistrationUI for IApplicationAssociationRegistrationUI
-Added COMDLG_FILTERSPEC struct (IFileOpenDialog/IFileSaveDialog)
-Added SysCommands enum (SC_ values; SC_CLOSE, SC_MINIMIZE, etc)
-FILEOPENDIALOGOPTIONS enum was missing FOS_SUPPORTSTREAMABLEITEMS
-Bug fix: Some features listed as included in 3.8 weren't in the release posted.
-(mIID) Added all IIDs for new interfaces
-(mIID) Added all known other SID_ values

i have one question after reading ur post

Code:

---

oleexpimp.tlb and mimelib.tlb have been compiled against oleexp 4.1
-oleexpimp.tlb - Expanded fork of olelib2.tlb, replaces olelib2.tlb; replace all 'olelib2.<type>' with 'oleexpimp.<type>'
-mimelib.tlb - same as the original except compiled against oleexp; won't work with it otherwise.

---

does oleexp 4.1 include oleexpimp or mimelib?
what is the differences?

They're both included in oleexp41.zip, in the Implements and mime folders respectively. Oleexpimp is like olelib2, it has versions of certain interfaces that can be used with the Implements keyword in a class, where the version in oleexp.tlb cannot. Mimelib is for working with mime, a very specific set of apis. Neither of these need to be included unless you're using them.

You spoiled it for me! I thought you were working with pimps and mimes... ;)

Saving that for oleexp v6.9 :eek:

Looks like if there is an error in exp_explrvw.odl for IExplorerPaneVisibility. If I try to implement the interface in a class module I get a 'bad interface implementation' error due to the out-parameter.
I changed the declaration for GetPaneState to

Code:

---

    HRESULT GetPaneState(
                [in] UUID *ep,
                [in, out] EXPLORERPANESTATE *peps);

---

and recompiled the tlb. I can then implement IExplorerPaneVisibility - e.g. in your Explorer Sample/frmBasic. Nevertheless the method is never called.
What's wrong? The declaration? Or is something missing to get the implemnt to work?
(I didn't fully understand the related MSDN information for this interface as they talk about an additional implementation of IServiceProvider for the hosting class...)

How is it going with x64 support? I couldn't succeed even with x86 version build on my machine. Even with older tools versions. Could you please provide detailed HOWTO to build your TLB? I mean, environment, commands, etc.? It would be very helpful!

Quote:

---

Originally Posted by deBUGer

How is it going with x64 support? I couldn't succeed even with x86 version build on my machine. Even with older tools versions. Could you please provide detailed HOWTO to build your TLB? I mean, environment, commands, etc.? It would be very helpful!

---

x64 support :eek: :confused:

This typelib wasn't built with x64 in mind, the types are (painstakingly) hard coded to 32bit / VB6 so that it can be used in VB6.

Are you using this from MS Office (x64)?

Quote:

---

Originally Posted by DEXWERX

x64 support :eek: :confused:

This typelib wasn't built with x64 in mind, the types are (painstakingly) hard coded to 32bit / VB6 so that it can be used in VB6.

Are you using this from MS Office (x64)?

---

Yes. Well, I don't need all the types, just very few of them - i.e. ITypeInfo, IDispatch, etc. These must have x64 bit support. But still - I get same errors even if I try to build this lib for x86. That's why I'm asking - how did you managed to do this?

Quote:

---

Originally Posted by deBUGer

Yes. Well, I don't need all the types, just very few of them - i.e. ITypeInfo, IDispatch, etc. These must have x64 bit support. But still - I get same errors even if I try to build this lib for x86. That's why I'm asking - how did you managed to do this?

---

modify mkex4.bat to point to your copy of mktyplib.exe

mine looks more like this.

Code:

---

REM C:\PROGRA~2\MIB055~1\VC98\Bin\MKTYPLIB.exe oleexp.odl
"C:\Program Files\Microsoft Visual Studio\Common\Tools\VB\typlib\mktyplib.exe" oleexp.odl

---

then run it. Or just run the full command from a console.


Now a question for you - What ODL type is used for pointers in VBA x64 ?



fafalone might need to convert this to MIDL before supporting 64bit.
Last I checked he didn't know how to "redefine" built in types.

In order to do that, you need to copy some of the base files like "unknwn.idl"
into the project directory so that those are included instead of the ones from the SDK/DDK folder.
Then you can modify the definitions in those files directly to get around MIDL's redefinition error.

Credit goes to Bruce McKinney for figuring that out (although he had help from MS). he created WinU.tlb
My typelibs all use MIDL also.

An example of this: http://vb.mvps.org/hardweb/mckinney2a.htm



As for converting the interfaces and APIs to VBA x64 - it's ground seldom tread.
You are better off starting a typelib from scratch than using oleexp.tlb.
and then there's the issue of distributing your source - unless you replace all the MS code, you can't distribute it legally.

Bruce McKinney (and then the company who took over the typelib) worked out licensing with MS.

Quote:

---

Originally Posted by DEXWERX

modify mkex4.bat to point to your copy of mktyplib.exe

mine looks more like this.

Code:

---

REM C:\PROGRA~2\MIB055~1\VC98\Bin\MKTYPLIB.exe oleexp.odl
"C:\Program Files\Microsoft Visual Studio\Common\Tools\VB\typlib\mktyplib.exe" oleexp.odl

---

then run it. Or just run the full command from a console.


Now a question for you - What ODL type is used for pointers in VBA x64 ?
long long ?

---

Well, I have already tried that. I get

Code:

---

Microsoft (R) Type Library Generator  Version 2.20.4230
Copyright (c) Microsoft Corp. 1993-1995.  All rights reserved.

fatal error M0006: unable to pre-process input file

---

--------------------

Finally I managed to compile it. The reason for M0006 was missing mspdb60.dll on my OS. Placing it next to cl.exe did the job. It builds now.

Can you please clarify what you expect a 64-bit compilation to provide?

This TLB is exclusively for VB. The only 64-bit scenario is if you're using 64-bit VBA in MS Office. The TLB works as-is in 64-bit VBA; the vast majority of types aren't 64-bit types to begin with, in the event there is a LongLong etc other types substitute. Refer to this post earlier in this thread.

These aren't original interfaces; what differences exist between the original 32-bit and 64-bit versions? IIRC there aren't two separate versions or major differences in the SDK the original defs are copied from.

==
Building the normal x86 version is just a matter of using MKTYPLIB from the Visual Studio 6 install; as DEXWERX mentioned there's a compile shortcut you can just edit the path for. There's no setting changes from the default install.


===
My problem with compiling with MIDL is that MIDL.EXE simply does not work. Period. For anything. Either oaidl is missing, and absolutely nothing, even a blank typelib, will compile without it, some other file is missing, or there's errors in oaidl or another pre-existing dpend file, whether precompiled or not, no matter which SDK version it comes from, no matter which SDK version MIDL.EXE comes from. Just can't get it to work even for a 'hello world' empty typelib, not a problem specific to oleexp. Fresh install of new VS version, no help. Running vcvarsall that came with the fresh install, no help. Every permutation of options and versions all has some excuse or another for not compiling at all.
It's extraordinarily frustrating, never in my life have I encountered a program so dedicated to not working.

the biggest difference is pointers. These obviously are 64-bit as opposed to 32-bit pointers in 32-bit windows. It's not just the returns from subs and the addresses of subs but also all handles. Microsoft says that to-date pointers are all of values that would fit in 32-bit variables even though addresses passed to/from function calls need the full 64 bits of space.

Here is what MSDN says regarding a call to the CopyFileEx function:

BOOL WINAPI CopyFileEx(
_In_ LPCTSTR lpExistingFileName,
_In_ LPCTSTR lpNewFileName,
_In_opt_ LPPROGRESS_ROUTINE lpProgressRoutine,
_In_opt_ LPVOID lpData,
_In_opt_ LPBOOL pbCancel,
_In_ DWORD dwCopyFlags
);

5 of the 6 parameters are 64-bit pointers to variables and a pointer to a callback routine. If the tlb says these are 32-bit pointers to be on the stack like in VB6 and Office 64 is making a call that 64-bit Windows expects to have 5 64-bit pointers then bad things are going to happen.

Forgive me for not being too familiar with this, but are you saying the 32-bit and 64-bit difference occurs in the same type? That on a 64-bit VBA a DWORD is no longer 4 bytes, instead of a new definition with an 8-byte variable?
How does the original source for declares like that handle things; is any change applied besides the 64-bit option for MIDL.exe?

If there's no changes and it's simply a compiler option, and someone can do that, I'd be happy to include the 64-bit version in the download, but honestly I've spent dozens of hours trying to compile anything with midl.exe and aren't really up to risking my sanity to keep fighting with it myself. I mean it's telling me an unmodified file from the official MS SDK is so full of errors it can't compile just by itself, and not one of the countless solutions found from googling the errors has helped... I'm just a poor old school VB programmer who never grew up into the more advanced languages and dev tools so it's already a challenge :blush:

MS defines a DWord the same in 32 and 64-bit programs. the difference is in pointers and handles. They even use the same words for handles and pointers but the compiler knows the difference. For example, in the previous example I posted a few minutes ago, I showed this:

Code:

---

BOOL WINAPI CopyFileEx(
_In_ LPCTSTR lpExistingFileName,
_In_ LPCTSTR lpNewFileName,
_In_opt_ LPPROGRESS_ROUTINE lpProgressRoutine,
_In_opt_ LPVOID lpData,
_In_opt_ LPBOOL pbCancel,
_In_ DWORD dwCopyFlags
);

---

LPCTSR lpExistingFileName is a pointer to the string holding the pathname of the file we want to copy. The "LP" in the name generally tells us that it is a pointer. In fact, it is is the equivalent of passing a parameter ByRef in VB6 or VBA since that passes the address on the stack instead of the actual variable itself. The compiler knows from switches that are set whether to treat the variable address as a 32 or 64-bit address.

My main exposure to the tlb-like world is via API Declare statements at the top of our code. Since in 32-bit VB or VBA there is no separate variable type for a handle, pointer or address everyone uses Long just like they do when they reference a DWord type which is our (VB) normal Long data type. That's fine in 32-bit but when we allow 64-bit then some of the Longs now have to become 64-bit instead of 32-bit. MS chose in 64-bit Office to cal this new variable type LongPtr and the compiler decides to make it 32 or 64 bit depending on whether the programmer is running 32 or 64-bit Office. So I don't know about type library code compilers but I am going to guess that the older ones that pre-date 64-bit OS's may not have a separate data type for handles, pointers and addresses but just show them as Longs. If so, then someone has a task to go back through the source and separate the DWords from the pointers and change all of the pointers to that new type (if there is one). I am hoping that this problem had come up in the shift from 16 to 32 bit and had been solved way back then but maybe not.

I'm certainly not a tlb wizard but I think the tlb info is static; I don't think it changes itself if it is being used in a 64 or 32-bit environment. I suppose it is possible for the type library file to adjust itself depending on whether the code is being compiled as a 32 or 64 bit program. My gut feel is that we need 2 separate type libraries and you make a reference to the appropriate one for whichever environment you are coding to.

Quote:

---

Originally Posted by fafalone

Can you please clarify what you expect a 64-bit compilation to provide?

This TLB is exclusively for VB. The only 64-bit scenario is if you're using 64-bit VBA in MS Office. The TLB works as-is in 64-bit VBA; the vast majority of types aren't 64-bit types to begin with, in the event there is a LongLong etc other types substitute.

---

Well, as you mentioned - I needed a few interfaces to be used in 64-bit VBA in MS Office. As other colleagues mentioned all the problems come from different pointers size. Namely, datastructure members and datapointers to data. It can be done by modifying ODL definitions. That's why I asked you to help with the build. Anyway, the problems with the build I had has been solved, so, no need to worry about that anymore.

Regarding using COM\OLE staff in Office VBA - it makes VBA programs bound to Windows platform. To support Office VBA on other platforms (like MAC) it's a very bad decision. So, I think it doesn't make much worth paying much attention to x64 bit COM\OLE staff.

Thanks to everyone for your replies and thoughts!

Well as mentioned when this first came up, in 64-bit VBA you can use a regular Long instead of LongPtr and the interfaces would work...

I'm still not entirely clear on the key point:
If you're using the interface natively, that is included from the original header/idl and not oleexp, are the arguments modified such that the ones expecting pointers now expect an 8-byte variable? Because recall the way things work, it matters, because if you change one argument to more bytes and it's not expected, then it breaks all the other arguments because there's no true separation.
To me it seems that if it *was* going to take 8-bytes in one argument that was previously 4, by the same principle you'd always have to pass 8 bytes or the rest of the alignment would be off too.

Honestly I think the first step here would be to find an API or interface in oleexp that does not work when called from 64-bit VBA. If one could be identified it would be a lot easier to figure things out.

@fafalone I run midl from the "VS x86 Tools Command Prompt" shortcut that automatically runs vcvarsall.bat passing x86 as a parameter

(Sorry for my bad language i m from germany and i have no english in school)

Hallo i need a lot of help..... please

I create a Url process Action ..... in VB6 with webbrowser control.

In the debug mode it runs fine by these url www.web.de.....
in executefile it crashes by these url www.web.de....

(a lot of other urls working fine)



i dont no whats wrong in the page ------ www.web.de ------ by execute or wrong in my code

i thing i make a lot of misstakes in my code or??????


thanks for your help


Implements oleexp.IInternetSecurityManager
Implements oleexpimp.IServiceProvider

Private SID_SProfferService As UUID
Private IID_IProfferService As UUID
Private IID_IInternetSecurityManager As UUID
Private ps As IProfferService
Private cookie As Long
Private sp As IServiceProvider

Public Function AddInternetSecurityManager() As Boolean

CLSIDFromString SIDSTR_SProfferService, IID_IProfferService
CLSIDFromString SIDSTR_SProfferService, SID_SProfferService
CLSIDFromString IIDSTR_IInternetSecurityManager, IID_IInternetSecurityManager

Set sp = wb.object
sp.QueryService SID_SProfferService, IID_IProfferService, ps

Call ps.ProfferService(IID_IInternetSecurityManager, Me)

End Function


Private Sub InternetSecurityManager_ProcessUrlAction(ByVal pwszUrl As Long, ByVal dwAction As oleexp.URLACTIONS, ByVal pPolicy As Long, ByVal cbPolicy As Long, pContext As Byte, ByVal cbContext As Long, ByVal dwFlags As oleexp.PUAF, ByVal dwReserved As Long)
Dim sURL As String
Dim i As Long
Dim B As Boolean

sURL = lpwstrPtrToString(pwszUrl)

If dwAction = URLACTION_SCRIPT_MIN Then

For i = 1 To ADS_SRC_COL.Count
If InStrB(LCase(sURL), ADS_SRC_COL(i)) > 0 Then
MoveMemory ByVal pPolicy, URLPOLICY_DISALLOW, 4&
B = True
Exit For
End If
Next i

If B = False Then 'Call MoveMemory(ByVal pPolicy, URLPOLICY_ALLOW&, 4&)
If RunningInIDE = False Then
Err.Raise oleexp.HRESULTS.INET_E_DEFAULT_ACTION
End If
End If

Else

If RunningInIDE = False Then Err.Raise oleexp.HRESULTS.INET_E_DEFAULT_ACTION

End If

End Sub


Private Sub IServiceProvider_QueryService(guidService As oleexp.UUID, riid As oleexp.UUID, ppvObject As Long)
Dim objUnknown As IUnknown
Dim lngResult As Long
Dim objISM As IInternetSecurityManager

If GetStringFromGUID(guidService) = UCase(IIDSTR_IInternetSecurityManager) Then
Set objUnknown = Me
objUnknown.AddRef
Set objISM = Me
MoveMemory ppvObject, objISM, 4&

Set objUnknown = Nothing
Set objISM = Nothing

Else
If RunningInIDE = False Then Err.Raise oleexp.HRESULTS.E_NOINTERFACE
End If

End Sub

Hallo from Germany,

I need help ....

in debug mode it runs by these side --- www.web.de --- perfect...

in execute it crashes i dont no why...

I test it with vbMHWB control crash project.exe (run in debug mode)
I test it with WB control olelib / olelib2 crash project.exe (run in debug mode)
and now with WB control oleexp / oleexpimp crash project.exe (run in debug mode)


please can any one help me to solve this problem?

Other sides run in debug mode and in execute mode perfect

I use vb6 SP6

here is the code... i do for testing



Regards Frank Tabacchi


Implements oleexp.InternetSecurityManager
Implements oleexpimp.IServiceProvider

Private SID_SProfferService As UUID
Private IID_IProfferService As UUID
Private IID_IInternetSecurityManager As UUID
Private ps As IProfferService
Private cookie As Long
Private sp As IServiceProvider

Private Sub Form_Load()

CLSIDFromString SIDSTR_SProfferService, IID_IProfferService
CLSIDFromString SIDSTR_SProfferService, SID_SProfferService
CLSIDFromString IIDSTR_IInternetSecurityManager, IID_IInternetSecurityManager

Set sp = wbBrowser.object

DoEvents

sp.QueryService SID_SProfferService, IID_IProfferService, ps

DoEvents

cookie = ps.ProfferService(IID_IInternetSecurityManager, Me)

wbBrowser.Silent = False

wbBrowser.Navigate "http://www.web.de"


End Sub

Private Sub Form_Unload(Cancel As Integer)
If cookie <> 0 Then
ps.RevokeService cookie
End If
End Sub

Public Function GetStringFromGUID(X As UUID) As String
Dim s As String
Dim L As Long
s = String(100, 0)
L = StringFromGUID2(X, s, Len(s))
GetStringFromGUID = UCase(Left(s, L - 1))
End Function

Private Function lpwstrPtrToString(ByVal lpwstrPtr As Long) As String
Dim lSize As Long
If lpwstrPtr <> 0 Then
lSize = lstrlenW(ByVal lpwstrPtr)
If lSize > 0 Then
ReDim b(0 To (lSize * 2) - 1) As Byte
MoveMemory b(0), ByVal lpwstrPtr, lSize * 2
lpwstrPtrToString = b
End If
End If
End Function

Private Function RunningInIDE() As Boolean
On Error Resume Next
Debug.Print 1 / 0
RunningInIDE = (Err <> 0)
End Function

Private Sub InternetSecurityManager_GetSecurityId(ByVal pwszUrl As Long, ByVal pbSecurityId As Long, pcbSecurityId As Long, ByVal dwReserved As Long)
If RunningInIDE = False Then Err.Raise oleexp.HRESULTS.INET_E_DEFAULT_ACTION
End Sub

Private Function InternetSecurityManager_GetSecuritySite() As oleexp.IInternetSecurityMgrSite
If RunningInIDE = False Then Err.Raise oleexp.HRESULTS.INET_E_DEFAULT_ACTION
End Function

Private Sub InternetSecurityManager_GetZoneMappings(ByVal dwZone As Long, ppenumString As oleexp.IEnumString, ByVal dwFlags As Long)
If RunningInIDE = False Then Err.Raise oleexp.HRESULTS.INET_E_DEFAULT_ACTION
End Sub

Private Sub InternetSecurityManager_MapUrlToZone(ByVal pwszUrl As Long, pdwZone As Long, ByVal dwFlags As Long)
If RunningInIDE = False Then Err.Raise oleexp.HRESULTS.INET_E_DEFAULT_ACTION
End Sub

Private Sub InternetSecurityManager_ProcessUrlAction(ByVal pwszUrl As Long, ByVal dwAction As oleexp.URLACTIONS, ByVal pPolicy As Long, ByVal cbPolicy As Long, pContext As Byte, ByVal cbContext As Long, ByVal dwFlags As oleexp.PUAF, ByVal dwReserved As Long)
If RunningInIDE = False Then Err.Raise oleexp.HRESULTS.INET_E_DEFAULT_ACTION
End Sub

Private Sub InternetSecurityManager_QueryCustomPolicy(ByVal pwszUrl As Long, guidKey As oleexp.UUID, ppPolicy As Long, pcbPolicy As Long, pContext As Byte, ByVal cbContext As Long, Optional ByVal dwReserved As Long = 0&)
If RunningInIDE = False Then Err.Raise oleexp.HRESULTS.INET_E_DEFAULT_ACTION
End Sub

Private Sub InternetSecurityManager_SetSecuritySite(ByVal pSite As oleexp.IInternetSecurityMgrSite)
If RunningInIDE = False Then Err.Raise oleexp.HRESULTS.INET_E_DEFAULT_ACTION
End Sub

Private Sub InternetSecurityManager_SetZoneMapping(ByVal dwZone As Long, ByVal lpszPattern As Long, ByVal dwFlags As oleexp.SZM_FLAGS)
If RunningInIDE = False Then Err.Raise oleexp.HRESULTS.INET_E_DEFAULT_ACTION
End Sub

Private Sub IServiceProvider_QueryService(guidService As oleexp.UUID, riid As oleexp.UUID, ppvObject As Long)
Dim objUnknown As oleexp.IUnknown
Dim lngResult As Long
Dim objISM As InternetSecurityManager

If GetStringFromGUID(guidService) = UCase(IIDSTR_IInternetSecurityManager) Then
Set objUnknown = Me
objUnknown.AddRef
Set objISM = Me
MoveMemory ppvObject, objISM, 4&
Else
If RunningInIDE = False Then Err.Raise oleexp.HRESULTS.INET_E_DEFAULT_ACTION
End If

End Sub

I'm unable to replicate the problem; the compiled EXE does not crash on my system, Win7, although web.de does throw 100 javascript error messages at me in both IDE and EXE. What version of Windows are you on? Or do I need to do more than just run the code to trigger the crash? Or other references/module and in what order?

Can you identify the line or at least procedure where it crashes? It's hard to locate the problem since IDE vs EXE issues aren't clearly visible errors; they're generally caused by the difference in memory handling.

I can identify a couple considerations however... you're returning entirely different values for RunningInIDE=False. Err.Raise, in some but not all COM interfaces, gets reported back as the HRESULT, so you're essentially returning S_OK (0) in the IDE and INET_E_DEFAULT_ACTION (0x800C0011) in the EXE, in a lot of subs.

----
PS- Please enclose code in tags: [CODE]'code here[/CODE]

Hallo again,

thanks for answer here... i had a attachment where the crash starts


Unfortunately, I'm not as deep in the topic as you

So I can not find a solution without your help here

Thanks again fore your help....


reguards Frank

What do I need to do to trigger a crash? I ran the exe, and also compiled it again, and clicked the button, it did not crash either time:
http://i.imgur.com/23vo0vD.jpg?1

I tested in Windows 8.1 as well, it did not crash then either.
----
Is this what you mean:
http://i.imgur.com/eCHNeZp.jpg?1

???

I get that in the IDE too but it's an issue with the browser control, not with VB code.

Hallo again,

My system is Win7 home premium SP1 / (IE11) and VB6 SP6

it is crazy... in my system the execute file is crashed...

TEST: I open the project.exe file and then i click the test button Web.de and then Win7 show
a msgbox the project1 is not functional do you want to send the problem to mircosoft......

By click the button i dont get any script errors and i dont see the webside on my screen i get the system (win7) message immediately
and then good by project1.exe but in debug mode it runs i dont no wat is going on, have you any idee or a sample that working in Win7?

I get this crash in Win XP / Win Vista and in Win7 (IE 11) all systems are german.

Help I'm too stupid to understand that... by test with the vbMHWB control (from www.codeproject.com) it is the same problem!
And they are more professional than me but it is crash to and ohter side are working.....


Can it be, that the crash coming because the site checks if jawascrict is active and that causes the crash?
Is this a zone security problem with german Windows (IE 9 10 11)?

When I comment out the code lines then the Webbrowser control working fine with the side but when i implements the function
then it crashed in execute mode.

this was killing me i testing a long time to solve this problem but i am have not any idee and any solution fore this...

that makes me sick.


Thanks for all writing and helping hands


Frank