It turns out this is easier to code in assembler than in "C" because everything is obvious and there are no compiler quirks to be circumvented. The attached asm file of 6KB (renamed FileOpenDialog.txt so it can be uploaded to the forum) contains all the code and there are no includes! When assembled and linked, this simple program shows a Windows open file dialog and displays the chosen file in a message box. This also demonstrates using iShellItem to assist in the process.
[EDIT] Sorry couple of small changes to the attachment - changed flag to CoInitializeEx and slight change to Release call
OK, I'm looking at that.
So what is the advantage of using that, what with all the CoInvoke stuff required, over just using the standard Win32 GetOpenFileName(), which I use all the time?
Setting up that dialog is pretty simple and doesn't require all that C++ baggage.
Well, the Windows documentation says:
QuoteStarting with Windows Vista, the Common Item Dialog supersedes the older Common File Dialog when used to open or save a file. The Common Item Dialog is used in two variations: the Open dialog and the Save dialog. These two dialogs share most of their functionality, but each has its own unique methods.
and
QuoteThe Common Item Dialog implementation found in Windows Vista provides several advantages over the implementation provided in earlier versions:
Supports direct use of the Shell namespace through IShellItem instead of using file system paths.
Enables simple customization of the dialog, such as setting the label on the OK button, without requiring a hook procedure.
Supports more extensive customization of the dialog by the addition of a set of data-driven controls that operate without a Win32 dialog template. This customization scheme frees the calling process from UI layout. Since any changes to the dialog design continue to use this data model, the dialog implementation is not tied to the specific current version of the dialog.
Supports caller notification of events within the dialog, such as selection change or file type change. Also enables the calling process to hook certain events in the dialog, such as the parsing.
Introduces new dialog features such as adding caller-specified places to the Places bar.
In the Save dialog, developers can take advantage of new metadata features of the Windows Vista Shell.
Okay, good answer.
One question: where do you find the documentation for all of those "methods" and other stuff needed to implement COM in assembly language?
Well, the Windows documentation is available online at https://learn.microsoft.com/en-gb/ (https://learn.microsoft.com/en-gb/) but in the case of COM you would be hard pressed to be able to work from that alone. There are examples there in "C++" so it's a matter of using those examples to get back to basics by trying to rewrite the example in assembler and then with a bit of experimentation eventually things start to work ..
One problem is that COM can be, or must be, implemented in several different ways as can be seen from the examples at http://www.godevtool.com (http://www.godevtool.com)
Hi Jorgon,
Welcome back :thup:
I have the same questions as NoCForMe, thanks for answering them. In practice, we have found ways to implement the new features with the old version but still, your code is extremely useful. Sooner or later it's time to throw the old FileOpen/FileSave stuff into the dustbin :cool:
Quote from: jorgon on February 19, 2025, 04:31:28 PMWell, the Windows documentation is available online at https://learn.microsoft.com/en-gb/ (https://learn.microsoft.com/en-gb/) but in the case of COM you would be hard pressed to be able to work from that alone. There are examples there in "C++" so it's a matter of using those examples to get back to basics by trying to rewrite the example in assembler and then with a bit of experimentation eventually things start to work ..
One problem is that COM can be, or must be, implemented in several different ways as can be seen from the examples at http://www.godevtool.com (http://www.godevtool.com/)
Thanks, but I wonder if you could post at least one of those C++ examples (or just a link to one).
But even if one has such an example, how does one get the contents with which to populate the needed structures, like, say,
IFileOpenDialog? Aren't all those things hidden within the C++ classes or methods or whatever? or do those functions all exist explicitly in the C++ code?
Wait just a minute: I just looked at those jump tables (that's what they are, right? or some other kind of dispatching table), and they're all zeroes. How does that work???
They're all structures.
STRUCT-ENDS in GoAsm declares a structure.
Yes it's true the zeroes could have been left out, but I quite like them.
And the blurb says:
QuoteHere is a structure declaration containing the vtable for the FileOpenDialog interface.
At compile time this gives the offset into the vtable of the particular function being called
This table comes from ShObjidl_core.h
The vtable is in Windows data/memory and at runtime all you have is a pointer to it (in iFILEOPENDIALOG).
And you get the offset into that table for the function from the structure.
So for example if you want to call "Show" the structure tells you that the offset is +0Ch
And so the actual call is:
MOV EAX,[iFILEOPENDIALOG]
CALL [EAX+0Ch]
That is dealt with by the CoInvoke macro.
Quote from: NoCforMe on February 20, 2025, 02:55:28 PMThanks, but I wonder if you could post at least one of those C++ examples (or just a link to one).
https://learn.microsoft.com/en-us/windows/win32/learnwin32/example--the-open-dialog-box (https://learn.microsoft.com/en-us/windows/win32/learnwin32/example--the-open-dialog-box)
Quote from: jorgon on February 20, 2025, 03:59:54 PMThey're all structures.
Yeah, yeah, I get that: I'm an assembler programmer, even though I don't use GoAsm.
But what I don't get is:
QuoteAnd so the actual call is:
MOV EAX,[iFILEOPENDIALOG]
CALL [EAX+0Ch]
That is dealt with by the CoInvoke macro.
But from looking at the source you provided, the value of
[EAX+0Ch] is
zero, right? Which of course would result in a fault.
Does that vtable get filled in at runtime somehow magically?
Quote from: jorgon on February 20, 2025, 04:06:08 PMQuote from: NoCforMe on February 20, 2025, 02:55:28 PMThanks, but I wonder if you could post at least one of those C++ examples (or just a link to one).
https://learn.microsoft.com/en-us/windows/win32/learnwin32/example--the-open-dialog-box (https://learn.microsoft.com/en-us/windows/win32/learnwin32/example--the-open-dialog-box)
Nowhere in that example do I see any of those vtable members you put in your structures.
Where do those come from?
In:
MOV EAX,[iFILEOPENDIALOG]
CALL [EAX+0Ch]
First line: EAX is given a pointer to the vtable held in Windows memory/data.
Second line: your exe calls the value 12 bytes into the vtable held in Windows memory/data. This is the address in the Windows code of the function that your exe wants to call.
This address is a value put into the vtable held in Windows memory/data when the COM interface is loaded. This address will probably change from time to time as the COM dlls are updated.
Quote from: NoCforMe on February 20, 2025, 04:19:14 PMNowhere in that example do I see any of those vtable members you put in your structures.
Where do those come from?
As mentioned in my file the vtable members come from the Windows header file ShObjidl_core.h
But they are probably also in shobjidl.h which is given as an include file in the C++ example. That's one reason why I don't like to use includes. You would have to search the include file to understand how the example code works.
Quote from: jorgon on February 20, 2025, 04:33:47 PMQuote from: NoCforMe on February 20, 2025, 04:19:14 PMNowhere in that example do I see any of those vtable members you put in your structures.
Where do those come from?
As mentioned in my file the vtable members come from the Windows header file ShObjidl_core.h
But they are probably also in shobjidl.h which is given as an include file in the C++ example. That's one reason why I don't like to use includes. You would have to search the include file to understand how the example code works.
OK. So where does one get those files? I don't have any C compilers here, no Visual Studio, none of that stuff.
Sorry to keep bugging you, but your answers only trigger more questions.
Quote from: jorgon on February 20, 2025, 04:27:17 PMIn:
MOV EAX,[iFILEOPENDIALOG]
CALL [EAX+0Ch]
First line: EAX is given a pointer to the vtable held in Windows memory/data.
Second line: your exe calls the value 12 bytes into the vtable held in Windows memory/data. This is the address in the Windows code of the function that your exe wants to call.
This address is a value put into the vtable held in Windows memory/data when the COM interface is loaded. This address will probably change from time to time as the COM dlls are updated.
So as I wrote, the vtables get filled in at runtime, right?
And when exactly is the COM interface loaded? Is it the call to
CoInitializeEx()?
Quote from: NoCforMe on February 20, 2025, 05:14:34 PMOK. So where does one get those files? I don't have any C compilers here, no Visual Studio, none of that stuff.
Sorry to keep bugging you, but your answers only trigger more questions.
I believe there is a forum here called "MASM include files", which may have them.
As you say, you could download something like Visual Studio which has them.
Or I find it quite easy simply to put the name of the file in a search engine and they come up in a result in GitHub.
Quote from: NoCforMe on February 20, 2025, 05:17:24 PMAnd when exactly is the COM interface loaded? Is it the call to CoInitializeEx()?
I think it's more likely they are loaded in the call to CoCreateInstance, because it is only then that the system knows which part of the COM library you want to use. It will identify this from the GUIDs passed as parameters to that function (that is, the CLSID_ and the IID_) which identify the class of the "object" and the COM interface which you want to use respectively.
I haven't checked this in the debugger.
The MASM include files subforum (and its subforum Windows include files) doesn't contain any of those files.
You mentioned ShObjidl_core.h; that's not even an assembler include file (which would be an .inc file).
I'm not about to mess around with Visual Studio.
OK, I found that header file in some GitHub repository: https://github.com/tpn/winsdk-10/blob/master/Include/10.0.14393.0/um/ShObjIdl_core.h
Looking through it, I find a bunch of what look like vtable structures, like so:
typedef struct IShellLinkWVtbl
{
BEGIN_INTERFACE
HRESULT ( STDMETHODCALLTYPE *QueryInterface )(
__RPC__in IShellLinkW * This,
/* [in] */ __RPC__in REFIID riid,
/* [annotation][iid_is][out] */
_COM_Outptr_ void **ppvObject);
ULONG ( STDMETHODCALLTYPE *AddRef )(
__RPC__in IShellLinkW * This);
ULONG ( STDMETHODCALLTYPE *Release )(
__RPC__in IShellLinkW * This);
However, comparing it to what you posted, I'm expecting to find the following sequence of "methods" (I guess that's what they're called in C++?):
- QueryInterface
- AddRef
- Release
- Show
which is what you have in your vtable,
IFileOpenDialog.
But there's no such sequence in that header file. Nor is there anything like what you called your structure, "IFileOpenDialog".
So what am I missing here?
Quote from: NoCforMe on February 20, 2025, 06:03:18 PMThe MASM include files subforum (and its subforum Windows include files) doesn't contain any of those files.
In the WinInc include files there are some assembly COM include files, also ShlobjIdl.inc: https://github.com/Baron-von-Riedesel/WinInc/tree/main/Include (https://github.com/Baron-von-Riedesel/WinInc/tree/main/Include)
I doubt however, that they are easier to read/understand than their C++ counterparts.
Quote from: NoCforMe on February 20, 2025, 06:03:18 PMSo what am I missing here?
You're lacking the basics of COM knowledge.
It's not that hard, actually. A COM object usually is a dynamically allocated STRUCT. It's not allocated by you, but usually by a dll that implements the COM object - if you call CoCreateInstance (or similar functions), the dll will allocate and initialize that STRUCT. However, for you ( or rather: your program ), all members of the STRUCT are hidden, except one: the ominous VTBL. So all you can do with that STRUCT is to call functions included in that "virtual function table".
QuoteBut there's no such sequence in that header file. Nor is there anything like what you called your structure, "IFileOpenDialog".
So what am I missing here?
Well, this is where, as an assembler programmer, you have to clean up the mess.
If you go to this part of the ShObjIdl_core.h file:
#ifdef COBJMACROS
#define IFileOpenDialog_QueryInterface(This,riid,ppvObject) \
( (This)->lpVtbl -> QueryInterface(This,riid,ppvObject) )
#define IFileOpenDialog_AddRef(This) \
( (This)->lpVtbl -> AddRef(This) )
#define IFileOpenDialog_Release(This) \
( (This)->lpVtbl -> Release(This) )
#define IFileOpenDialog_Show(This,hwndOwner) \
( (This)->lpVtbl -> Show(This,hwndOwner) )
#define IFileOpenDialog_SetFileTypes(This,cFileTypes,rgFilterSpec) \
( (This)->lpVtbl -> SetFileTypes(This,cFileTypes,rgFilterSpec) )
The definitions are easier to follow, and you can see that on the assumption that each #define is a dword (which they would be because each resolves to an address of a function in the vtable) then the first is QueryInterface, the second is AddRef and so on. The part in brackets after the name of the function contains the parameters and so this produces the table in my FileOpenDialog file.
Header file converters have been written to try to automate this but when you only want one vtable it can be done quite quickly on the keyboard.
But what you show isn't even in that file!
Don't believe me? Go there and do a search for "IFileOpenDialog". Not found.
(I'm referring to that GitHub file I linked to above. ShObjIdl_core.h)
Well, whaddya know: this file (https://github.com/tpn/winsdk-10/blob/master/Include/10.0.16299.0/um/ShObjIdl_core.h) has that stuff in it.
So now the question is, how do you even know which file (which version, I guess) to use?
This all is still very mysterious. Not the way it works--I get how the vtable works--but just how to find the right file and the code you need to create the structures in assembly language.
Still a lot of handwaving going on here ...
QuoteSo now the question is, how do you even know which file (which version, I guess) to use?
Yes exactly.
If you look on the internet at the problems higher level programmers raise, they are quite often whether the platform is properly set up with the correct files, the correct configuration etc.
As assembler programmers we are able to reduce these issues to the minimum.
Since the header files or includes come in different versions but with the same names, I much prefer to have that part of the includes in the asm file itself.
I'm wondering whether I've earned my award yet.
Well, that's nice, but you didn't answer the question. So sorry, no award for you yet.
I still have no clue how to determine which version of a file (say, ShObjIdl_core.h) is the correct one. Or, let's say, a version that will at least work for converting to an .inc file. (And yes, I can do that by hand.)
The latest version will be in the latest Windows Kit (currently 10.0.26100.0).
And what is the Windows Kit, pray tell?
Windows SDK (https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/)
Quote from: NoCforMe on February 20, 2025, 07:22:52 PMWell, that's nice, but you didn't answer the question. So sorry, no award for you yet.
I still have no clue how to determine which version of a file (say, ShObjIdl_core.h) is the correct one. Or, let's say, a version that will at least work for converting to an .inc file. (And yes, I can do that by hand.)
In order to win my award, I answer as follows.
You can't tell which is the correct one, apart from looking inside to see if it has what you are looking for, but it matters a lot less than you would think because the names of the functions, the number of parameters the function expects, and the types of those parameters will never change. If they did, progs compiled using the old headers would fail.
GoAsm does not check that the number or types of parameters matches those in the header file, so getting the correct header file is even less important. So GoAsm works without any header files or includes. This means that in GoAsm if you pass the wrong number or type of parameter to a Windows API the prog just crashes. If this happens you can check the code to see if you've passed the correct number or type of parameters to the API.
When calling a Windows API it is often crucial to get the structures passed to the API correct, and in GoAsm this can be done within the source code in the same way as you have seen from the FileOpenDialog file when calling a COM function.
DELETED
DELETED
I have a FileDialog library that implements the COM of IFileOpenDialog and IFileSaveDialog:
https://masm32.com/board/index.php?topic=12171.0 (https://masm32.com/board/index.php?topic=12171.0)
https://github.com/mrfearless/FileDialog-Library (https://github.com/mrfearless/FileDialog-Library)
Quotehttps://learn.microsoft.com/en-us/windows/win32/learnwin32/example--the-open-dialog-box
Nowhere in that example do I see any of those vtable members you put in your structures.
Where do those come from?
Maybe translation from C++ to MASM64 code without macros will help. :smiley:
#include <windows.h>
#include <shobjidl.h>
int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE, PWSTR pCmdLine, int nCmdShow)
{
HRESULT hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED |
COINIT_DISABLE_OLE1DDE);
;*******************************************************************;
xor ecx, ecx ; 2 = COINIT_APARTMENTTHREADED
mov edx, 2 or 4 ; 4 = COINIT_DISABLE_OLE1DDE ;Disables DDE for OLE1 support.
call CoInitializeEx
;*******************************************************************;
if (SUCCEEDED(hr))
{
;*******************************************************************;
test eax, eax
jne Ret_1 ; Exit with error
;*******************************************************************;
IFileOpenDialog *pFileOpen;
// Create the FileOpenDialog object.
hr = CoCreateInstance(CLSID_FileOpenDialog, NULL, CLSCTX_ALL,
IID_IFileOpenDialog, reinterpret_cast<void**>(&pFileOpen));
;*******************************************************************;
lea rax, pFileOpen ; Result: Interface CLSID_FileOpenDialog
lea r9, IID_IFileOpenDialog
mov [rsp+4*8], rax ; Interface CLSID_FileOpenDialog
mov r8d, CLSCTX_INPROC_SERVER ; CLSCTX_INPROC_SERVER = 1
xor edx, edx
lea rcx, CLSID_FileOpenDialog
call CoCreateInstance
;*******************************************************************;
if (SUCCEEDED(hr))
{
;*******************************************************************;
test eax, eax
jne Ret_1
;*******************************************************************;
// Show the Open dialog box.
hr = pFileOpen->Show(NULL);
;*******************************************************************;
mov rcx, pFileOpen ; rcx= Interface CLSID_FileOpenDialog
xor edx, edx ; parameter NULL for method Show
mov rax, [rcx] ; rax=addr of vTable
call qword ptr [rax+3*8] ; call method Show
; Methods (functions) from vTable of Interface CLSID_FileOpenDialog ;
; QueryInterface dq 0*8 ; *8 for 64 bit ; *4 for 32 bit
; AddRef dq 1*8
; Release dq 2*8
; Show dq 3*8
; SetFileTypes dq 4*8
; .......
; GetResult dq 27*8
;
;*******************************************************************;
// Get the file name from the dialog box.
if (SUCCEEDED(hr))
{
;*******************************************************************;
test eax, eax
jne Ret_1
;*******************************************************************;
IShellItem *pItem;
hr = pFileOpen->GetResult(&pItem);
;*******************************************************************;
mov rcx, pFileOpen ; rcx= Interface CLSID_FileOpenDialog
lea edx, pItem ; parameter pItem for method GetResult
mov rax, [rcx] ; rax=addr of vTable
call qword ptr [rax+27*8] ; call method GetResult
;*******************************************************************;
if (SUCCEEDED(hr))
{
;*******************************************************************;
test eax, eax
jne Ret_1
;*******************************************************************;
PWSTR pszFilePath;
hr = pItem->GetDisplayName(SIGDN_FILESYSPATH, &pszFilePath);
;*******************************************************************;
mov rcx, pItem ; IShellItem interface
lea r8, pszFilePath ; 2nd parameter of method(function) GetDisplayName
mov edx, 80058000h ; 1st parameter - 80058000h=SIGDN_FILESYSPATH
; SIGDN_FILESYSPATH - Returns the item's file system path, if it has one
mov rax, [rcx] ; vTable of interface IShellItem
call qword ptr [rax+5*8] ; call method GetDisplayName vTable of interface IShellItem
; 1st Part of IShellItemVtbl
; QueryInterface dq 0*8
; AddRef dq 1*8
; Release dq 2*8
; BindToHandler dq 3*8
; GetParent dq 4*8
; GetDisplayName dq 5*8
; ......
; Note: Search MS explanation for IShellItem::GetDisplayName for details about all
; parameters of method(function) GetDisplayName (SIGDN_FILESYSPATH,addr pszFilePath)
;*******************************************************************;
// Display the file name to the user.
if (SUCCEEDED(hr))
{
;*******************************************************************;
test eax, eax
jne Ret_1
;*******************************************************************;
MessageBoxW(NULL, pszFilePath, L"File Path", MB_OK);
;*******************************************************************;
mov r9d, MB_OK
lea r8, pszUFilePath
lea rdx, pszFilePath
xor ecx, ecx
call MessageBoxW
;*******************************************************************;
CoTaskMemFree(pszFilePath);
}
;*******************************************************************;
lea rcx, pszFilePath
call CoTaskMemFree
;*******************************************************************;
pItem->Release();
}
;*******************************************************************;
mov rcx, pItem
mov rax, [rcx]
call qword ptr [rax+2*8] ; call method Release from vTable of interface IShellItem
;*******************************************************************;
}
pFileOpen->Release();
}
;*******************************************************************;
mov rcx, pFileOpen
mov rax, [rcx]
call qword ptr [rax+2*8] ; call method Release from vTable of interface IShellItem
;*******************************************************************;
CoUninitialize();
}
return 0;
}
;*******************************************************************;
call CoUninitialize
xor eax, eax
ret
;*******************************************************************;
Result-> MASM64 code without macros :biggrin:
.data?
pFileOpen dq ?
pItem dq ?
pszFilePath dq ?
.data
pszUFilePath dw "F","i","l","e"," ","P","a","t","h",0,0
CLSID_FileOpenDialog dd 0DC1C5A9Ch
dw 0e88ah,4ddeh,a5a1h
db 60,0F8h,02ah,20h,0aeh,0f7h
IID_IFileOpenDialog dd d57c7288h
dw 0d4adh,4768h,0be02h
db 9dh,96h,95h,32h,0d9h,060h
.code
;*******************************************************************;
xor ecx, ecx ; 2 = COINIT_APARTMENTTHREADED
mov edx, 2 or 4 ; 4 = COINIT_DISABLE_OLE1DDE ;Disables DDE for OLE1 support.
call CoInitializeEx
test eax, eax
jne Ret_1 ; Exit with error
lea rax, pFileOpen ; Result: Interface CLSID_FileOpenDialog
lea r9, IID_IFileOpenDialog
mov [rsp+4*8], rax ; Interface CLSID_FileOpenDialog
mov r8d, CLSCTX_INPROC_SERVER ; CLSCTX_INPROC_SERVER = 1
xor edx, edx
lea rcx, CLSID_FileOpenDialog
call CoCreateInstance
test eax, eax
jne Ret_1
mov rcx, pFileOpen ; rcx= Interface CLSID_FileOpenDialog
xor edx, edx ; parameter NULL for method Show
mov rax, [rcx] ; rax=addr of vTable
call qword ptr [rax+3*8] ; call method Show
test eax, eax
jne Ret_1
mov rcx, pFileOpen ; rcx= Interface CLSID_FileOpenDialog
lea edx, pItem ; parameter pItem for method GetResult
mov rax, [rcx] ; rax=addr of vTable
call qword ptr [rax+27*8] ; call method GetResult
test eax, eax
jne Ret_1
mov rcx, pItem ; IShellItem interface
lea r8, pszFilePath ; 2nd parameter of method(function) GetDisplayName
mov edx, 80058000h ; 1st parameter - 80058000h=SIGDN_FILESYSPATH
; SIGDN_FILESYSPATH - Returns the item's file system path, if it has one
mov rax, [rcx] ; vTable of interface IShellItem
call qword ptr [rax+5*8] ; call method GetDisplayName vTable of interface IShellItem
test eax, eax
jne Ret_1
mov r9d, MB_OK
lea r8, pszUFilePath
lea rdx, pszFilePath
xor ecx, ecx
call MessageBoxW
lea rcx, pszFilePath
call CoTaskMemFree
mov rcx, pItem
mov rax, [rcx]
call qword ptr [rax+2*8] ; call method Release from vTable of interface IShellItem
mov rcx, pFileOpen
mov rax, [rcx]
call qword ptr [rax+2*8] ; call method Release from vTable of interface FileOpenDialog
call CoUninitialize
xor eax, eax
ret
Ret_1:
mov eax, 1
ret
DELETED
Quote from: jorgon on February 20, 2025, 08:30:45 PMQuote from: NoCforMe on February 20, 2025, 07:22:52 PMWell, that's nice, but you didn't answer the question. So sorry, no award for you yet.
I still have no clue how to determine which version of a file (say, ShObjIdl_core.h) is the correct one. Or, let's say, a version that will at least work for converting to an .inc file. (And yes, I can do that by hand.)
In order to win my award, I answer as follows.
You can't tell which is the correct one, apart from looking inside to see if it has what you are looking for, but it matters a lot less than you would think because the names of the functions, the number of parameters the function expects, and the types of those parameters will never change. If they did, progs compiled using the old headers would fail.
What??? Our course it matters, a lot.
Are you purposely being obtuse here? Because that first GitHub version of
ShObjIdl_core.h that I linked to above
did not even have the elements required to construct the IFileOpenDialog vtable.
I would say that totally matters.
I somehow get the feeling you're not really paying attention to my questions, because all I seem to get out of you is a lot of handwaving and vague answers. Might be my misperception, of course, but still ...
So is the only way to see whether a header file is suitable to open it and look for the specific structure members (and possibly other items, like #defines) you need? And how would you even know which ones to look for? What names do you use? Are they listed in the Micro$oft Learn documentation for the functions you'll be using?
QuoteI somehow get the feeling you're not really paying attention to my questions, because all I seem to get out of you is a lot of handwaving and vague answers.
Ask
QWEN CHAT and/or
Deep-Seek. :badgrin: :skrewy:
Quote from: ognil on February 21, 2025, 11:43:11 AMQuoteI somehow get the feeling you're not really paying attention to my questions, because all I seem to get out of you is a lot of handwaving and vague answers.
Ask QWEN CHAT and/or Deep-Seek. :badgrin: :skrewy:
No.
Quote from: TimoVJL on February 21, 2025, 09:21:39 AMCOM Dual Interface
Some COM object interfaces are for languages like VB and script languages, and those might use GetIDsOfNames() and Invoke() for methods, and can have a limited vTable
Timo--your tangential reply is not helpful at all.
DELETED
OK, Timo, I get it that those files can be found all over the place online.
Still doesn't answer my questions as to how to 1) find them and 2) confirm that they're suitable for your application.
Quote from: NoCforMe on February 21, 2025, 12:57:42 PMOK, Timo, I get it that those files can be found all over the place online.
Still doesn't answer my questions as to how to 1) find them and 2) confirm that they're suitable for your application.
1) Download the SDK
2) Convert the .H to a .INC and it's suitable
The Microsoft Learn page usually has which header file the interface is defined in.
One gotcha about the Learn page is that the methods are usually in alphabetical order, not vtable order :rolleyes:.
Quote from: sinsi on February 21, 2025, 01:39:05 PMOne gotcha about the Learn page is that the methods are usually in alphabetical order, not vtable order :rolleyes:.
Are they in the correct order in the header files? (I would guess by definition yes, but that's just a guess.)
Alphabetical order would make sense for C++ programmers, who don't have build a vtable: that's already done for them.
They should be in order, since that is the definition.
One thing to look for in the C++ definition is whether it inherits another interface
IShellLinkW : public IUnknownMost interfaces that I've seen inherit IUnknown, and that's the first few entries in the vtable.
It might be worthwhile looking at interfaces from the other side, there was an article in Stack Overflow (maybe Code Project) where someone went through building a simple interface in C.
Hey mods, this has grown beyond GoAsm ,maybe split it?
Quote from: jorgon on February 19, 2025, 11:31:58 AMIt turns out this is easier to code in assembler than in "C" because everything is obvious and there are no compiler quirks to be circumvented.
I don't understand what you mean:
1) Assembly + WinAPI is easier than C + WinAPI
or
2) GoAsm not needs WinAPI at all.
This was a reference to our being spared this sort of stuff as assembler programmers. This is from Microsoft's "COM Coding Practices" article here: https://learn.microsoft.com/en-us/windows/win32/LearnWin32/com-coding-practices (https://learn.microsoft.com/en-us/windows/win32/LearnWin32/com-coding-practices):
QuoteWhen you build your program, you might get linker errors similar to the following:
unresolved external symbol "struct _GUID const IID_IDrawable"
This error means that a GUID constant was declared with external linkage (extern), and the linker could not find the definition of the constant. The value of a GUID constant is usually exported from a static library file. If you are using Microsoft Visual C++, you can avoid the need to link a static library by using the __uuidof operator. This operator is a Microsoft language extension. It returns a GUID value from an expression. The expression can be an interface type name, a class name, or an interface pointer.
Using __uuidof, you can create the Common Item Dialog object as follows:
IFileOpenDialog *pFileOpen;
hr = CoCreateInstance(__uuidof(FileOpenDialog), NULL, CLSCTX_ALL,
__uuidof(pFileOpen), reinterpret_cast<void**>(&pFileOpen));
The compiler extracts the GUID value from the header, so no library export is necessary.
We saw that both CoCreateInstance and QueryInterface require coercing the final parameter to a void** type. This creates the potential for a type mismatch. Consider the following code fragment:
// Wrong!
IFileOpenDialog *pFileOpen;
hr = CoCreateInstance(
__uuidof(FileOpenDialog),
NULL,
CLSCTX_ALL,
__uuidof(IFileDialogCustomize), // The IID does not match the pointer type!
reinterpret_cast<void**>(&pFileOpen) // Coerce to void**.
);
This code asks for the IFileDialogCustomize interface, but passes in an IFileOpenDialog pointer. The reinterpret_cast expression circumvents the C++ type system, so the compiler will not catch this error. In the best case, if the object does not implement the requested interface, the call simply fails. In the worst case, the function succeeds and you have a mismatched pointer. In other words, the pointer type does not match the actual vtable in memory. As you can imagine, nothing good can happen at that point.
Note
A vtable (virtual method table) is a table of function pointers. The vtable is how COM binds a method call to its implementation at run time. Not coincidentally, vtables are how most C++ compilers implement virtual methods.
The IID_PPV_ARGS macro helps to avoid this class of error. To use this macro, replace the following code:
__uuidof(IFileDialogCustomize), reinterpret_cast<void**>(&pFileOpen)
with this:
IID_PPV_ARGS(&pFileOpen)
The macro automatically inserts __uuidof(IFileOpenDialog) for the interface identifier, so it is guaranteed to match the pointer type. Here is the modified (and correct) code:
// Right.
IFileOpenDialog *pFileOpen;
hr = CoCreateInstance(__uuidof(FileOpenDialog), NULL, CLSCTX_ALL,
IID_PPV_ARGS(&pFileOpen));
You can use the same macro with QueryInterface:
IFileDialogCustomize *pCustom;
hr = pFileOpen->QueryInterface(IID_PPV_ARGS(&pCustom));
If compiler not works as it should, then creators of compiler should make it work as it should.
No?
Define "as it should".
See the problem?
Quote from: NoCforMe on February 22, 2025, 04:08:04 PMDefine "as it should".
See the problem?
Compiler VC++ has system problem which its creators are not able to solve. But OP has bypassed problem. Correct?
Sure, bypassed it by not using C++!
So what C++ has to do with it at all, if thread is about GoAsm?
Quote from: Villuy on February 22, 2025, 07:35:23 PMSo what C++ has to do with it at all, if thread is about GoAsm?
I can at least
partially answer that. All of the documentation that Microsoft puts out for any of the Windows API's is mostly (entirely?) geared toward and written for C/C++ programmers. Also the source header files (*.h) are written for C/C++, the Microsoft variety, and it is left up to the assembly programmer to convert the C/C++ header files to assembly compatible include files (*.inc), either manually or via a third party or self written tool.
Therefor any discussion of using Microsoft Windows API's for assembly will, at some point, include discussing (Microsoft) C/C++ data types for structures, etc... Assembly language programmers are not bound to the assumptions/limitations imposed by MSVC/MSVC++ as far as data types, but must at least be familiar with those data types, in relation to assembly programming to properly make the conversion. :smiley:
At least that's my take on this...
Good point :thumbsup:
We wont see any MS documentation in C anymore, just in C++
Quote from: zedd151 on February 22, 2025, 11:26:16 PMTherefor any discussion of using Microsoft Windows API's for assembly will, at some point, include discussing (Microsoft) C/C++ data types for structures, etc... Assembly language programmers are not bound to the assumptions/limitations imposed by MSVC/MSVC++ as far as data types, but must at least be familiar with those data types, in relation to assembly programming to properly make the conversion. :smiley:
+1
Before x64 it used to be "everything is a DWORD" :angelic:
Quote from: sinsi on February 22, 2025, 11:47:24 PMBefore x64 it used to be "everything is a DWORD"
Nowadays it's "either a pointer or a handle, or a DWORD" :biggrin:
Quote from: jj2007 on February 22, 2025, 11:54:10 PMQuote from: sinsi on February 22, 2025, 11:47:24 PMBefore x64 it used to be "everything is a DWORD"
Nowadays it's "either a pointer or a handle, or a DWORD" :biggrin:
or qword. :tongue:
Quote from: jj2007 on February 22, 2025, 11:54:10 PMQuote from: sinsi on February 22, 2025, 11:47:24 PMBefore x64 it used to be "everything is a DWORD"
Nowadays it's "either a pointer or a handle, or a DWORD" :biggrin:
My combined 32/64 bit
windows.inc starts with
IFDEF __WIN64__
_align_ = 8
HANDLE typedef qword
POINTER typedef qword
ELSE
_align_ = 4
HANDLE typedef dword
POINTER typedef dword
ENDIF
:badgrin:
Quote from: zedd151 on February 22, 2025, 11:26:16 PMI can at least partially answer that.
All this is clear. But why we are discussing compiler VC++ problems here?
DELETED
Quote from: Villuy on February 23, 2025, 01:42:37 AMBut why we are discussing compiler VC++ problems here?
It's a hobby for some. :tongue:
Quote from: TimoVJL on February 23, 2025, 01:52:36 AMjust a some stupid ideology as I have seen.
No C for someone is best example?
I not understanded your remark. Just like previous one.
Quote from: Villuy on February 23, 2025, 01:42:37 AMQuote from: zedd151 on February 22, 2025, 11:26:16 PMI can at least partially answer that.
All this is clear. But why we are discussing compiler VC++ problems here?
I think the answer to that should be obvious:
It's because the OP chose to code a function (actually an "interface",
IFileOpenDialog()) that uses a COM interface.
The COM interface stuff is really only documented (by Micro$oft and others) in C++/C form. Therefore it had to be "translated" from C++/C to assembly language.
And it turns out that doing things this way is less problematic than coding it in the native C++/C. Who would've guessed that?
Component Object Model (https://en.wikipedia.org/wiki/Component_Object_Model)
QuoteUnlike C++, COM provides a stable application binary interface (ABI) that is unaffected by compiler differences.[3] This makes using COM advantageous for object-oriented C++ libraries that are to be used by clients compiled via different compilers.
A COM structure??? I would have. C'mon. As would someone with enough knowledge to write the GoAsm assembler in the first place.
NoC, respectfully (if it is possible), take a breath. Please. It is glaringly obvious that assembly language is something you "dabble" in, but otherwise don't know jack about. And, that's being nice. We are treated to one misguided, angry opinion after another, on every topic -- it's truly maddening at times.
I'm just asking for a little detente, that's all. It seems like every last topic is railroaded directly into the ground, and in this case you're trying to make an ACTUAL assembler author jump through hoops over a COM structure you know nothing about. Why? Who thinks that's right?
I don't. And I don't do it to you. Neither does anyone else. How else can I make the point? It needs to stop, and only one guy needs to figure out how. In other words, be nice or go away. Enough is enough. This is 2025. Smarter, more kind. All the time. Or bust.
Sorry, not sorry.
Going to ignore your "advice".
Okay.
Quote from: NoCforMe on February 23, 2025, 07:07:34 AMI think the answer to that should be obvious:
Quote from: TimoVJL on February 23, 2025, 07:58:03 AMUnlike C++, COM provides a stable application binary interface (ABI) that is unaffected by compiler differences. This makes using COM advantageous for object-oriented C++ libraries that are to be used by clients compiled via different compilers.
Interfaces are drug addict's thing in WinAPI. So probably yes.
Quote from: Villuy on February 23, 2025, 03:08:35 AMQuote from: TimoVJL on February 23, 2025, 01:52:36 AMjust a some stupid ideology as I have seen.
No C for someone is best example?
I not understanded your remark. Just like previous one.
I don't understand it either, Timo: it's difficult to figure out exactly what you're trying to say because of your fractured English syntax. Are you saying that I (NoC) am the best example of stupid ideology? or did you mean something else?
I think you can probably tell why I don't exactly appreciate the comment ...
Quote from: Villuy on February 23, 2025, 02:51:00 PMInterfaces are drug addict's thing in WinAPI. So probably yes.
??????? Please explain. You don't like interfaces?
Quote from: NoCforMe on February 23, 2025, 04:44:51 PMYou don't like interfaces?
Interfaces seem inorganic, foreign matter in WinAPI.
OK.
Using the macros(within UASM64) will become simpler.
COMINTERFACE STIShellItem
;CVIRTUAL QueryInterface,QWORD,riid:QWORD ,ppvObject:QWORD
;CVIRTUAL AddRef,QWORD
;CVIRTUAL Release,QWORD
CVIRTUAL BindToHandler,QWORD,pbc:QWORD ,bhid:DWORD ,riid:QWORD ,ppv:QWORD
CVIRTUAL GetParent1,QWORD,ppsi:QWORD
CVIRTUAL GetDisplayName,QWORD,sigdnName:DWORD ,ppszName:QWORD
CVIRTUAL GetAttributes,QWORD,sfgaoMask:DWORD ,psfgaoAttribs:QWORD
CVIRTUAL Compare,QWORD,psi:QWORD ,hint:DWORD ,piOrder:QWORD
ENDCOMINTERFACE
@STIShellItem TYPEDEF PTR STIShellItem
COMINTERFACE STIFileOpenDialog
;CVIRTUAL QueryInterface,QWORD,riid:QWORD ,ppvObject:QWORD
;CVIRTUAL AddRef,QWORD
;CVIRTUAL Release,QWORD
CVIRTUAL Show,QWORD ,hwndOwner:HWND
CVIRTUAL SetFileTypes,QWORD ,cFileTypes:DWORD ,rgFilterSpec:QWORD
CVIRTUAL SetFileTypeIndex,QWORD ,piFileType:QWORD
CVIRTUAL GetFileTypeIndex,QWORD ,piFileType:QWORD
CVIRTUAL Advise,QWORD ,pfde:QWORD ,pdwCookie:QWORD
CVIRTUAL Unadvise,QWORD ,pfde:QWORD
CVIRTUAL SetOptions,QWORD ,pfos:QWORD
CVIRTUAL GetOptions,QWORD ,pfos:QWORD
CVIRTUAL SetDefaultFolder,QWORD ,psi:QWORD
CVIRTUAL SetFolder,QWORD ,psi:QWORD
CVIRTUAL GetFolder,QWORD ,ppsi:QWORD
CVIRTUAL GetCurrentSelection,QWORD ,ppsi:QWORD
CVIRTUAL SetFileName,QWORD ,pszName:QWORD
CVIRTUAL GetFileName,QWORD ,pszName:QWORD
CVIRTUAL SetTitle,QWORD ,pszTitle:QWORD
CVIRTUAL SetOkButtonLabel,QWORD ,pszText:QWORD
CVIRTUAL SetFileNameLabel,QWORD ,pszLabel:QWORD
CVIRTUAL GetResult,QWORD ,ppsi:QWORD
CVIRTUAL AddPlace,QWORD ,psi:QWORD ,fdap:DWORD
CVIRTUAL SetDefaultExtension,QWORD ,pszDefaultExtension:QWORD
CVIRTUAL Close,QWORD ,hr:QWORD
CVIRTUAL SetClientGuid ,QWORD ,rgFilterSpec:QWORD
CVIRTUAL ClearClientData,QWORD
CVIRTUAL SetFilter,QWORD ,pFilter:QWORD
CVIRTUAL GetResults,QWORD ,ppenum:QWORD
CVIRTUAL GetSelectedItems,QWORD ,ppsai:QWORD
ENDCOMINTERFACE
@FileOpen TYPEDEF PTR STIFileOpenDialog
.data
CLSID_FileOpenDialog \
dd 0dc1c5a9ch
dw 0e88ah
dw 04ddeh
db 0a5h,0a1h,060h,0F8h,02ah,20h,0aeh,0f7h
IID_IFileOpenDialog \
dd 0d57c7288h
dw 0d4adh
dw 04768h
db 0beh,02h,09dh,096h,095h,032h,0d9h,060h
.code
WorkerThreadFileOpen proc plPrm:QWORD
LOCAL wCaption[260]:BYTE
LOCAL pItem:@STIShellItem
LOCAL pFileOpen:@FileOpen
LOCAL pszFilePath:QWORD
invoke CoInitializeEx,NULL,2 or 4
test rax, rax
jne Ret_1 ; Exit with error
invoke CoCreateInstance,addr CLSID_FileOpenDialog, NULL, 1, addr IID_IFileOpenDialog,ADDR pFileOpen
test rax, rax
jne Ret_1
_VINVOKE pFileOpen,STIFileOpenDialog,Show,NULL ;COM API
test rax, rax
jne Ret_1
_VINVOKE pFileOpen,STIFileOpenDialog,GetResult,addr pItem ;COM API
test rax, rax
jne Ret_1
_VINVOKE pItem,STIShellItem,GetDisplayName,080058000h,addr pszFilePath ;COM API
test rax, rax
jne Ret_1
invoke RtlZeroMemory,ADDR wCaption,sizeof wCaption
invoke MultiByteToWideChar,CP_ACP,0,CStr("File Path"),-1,addr wCaption,256
invoke MessageBoxW,0,pszFilePath,ADDR wCaption,MB_OK
invoke CoTaskMemFree,pszFilePath
_VINVOKE pItem,STIShellItem,Release ;COM API
_VINVOKE pFileOpen,STIFileOpenDialog,Release ;COM API
invoke CoUninitialize
xor rax, rax
ret
Ret_1:
mov rax, 1
ret
WorkerThreadFileOpen endp
invoke CreateThread,NULL,NULL,offset WorkerThreadFileOpen,NULL,NULL,NULL
invoke CloseHandle,rax
Nice, thanks for the post six_L
My five cents: :smiley: :skrewy:
Q: What is more professional: pure asm code or asm code using macros in MASM64
A from Daobao: When considering the professionalism of pure assembly code versus assembly code using macros in MASM64 (Microsoft Macro Assembler), the answer is: pure assembly code. Below is a detailed analysis:
1. Pure Assembly Code**
Pure assembly code refers to writing assembly instructions without relying on macros or higher-level abstractions provided by the assembler.
**Advantages:**
- **Clarity of Intent:** Pure assembly code explicitly shows every instruction and operation, making it easier for someone reviewing the code to understand exactly what is happening at the hardware level.
- **Portability:** Pure assembly is less dependent on specific assembler features, making it more portable across different assemblers or platforms (assuming compatible instruction sets).
- **Debugging:** Debugging pure assembly can be simpler because there are no layers of abstraction that might obscure what the code is doing.
- **Learning Tool:** Writing pure assembly is an excellent way to deeply understand the architecture and instruction set of the processor.
**Disadvantages:**
**Error-Prone:** Repetitive code increases the likelihood of human error, such as typos or inconsistencies.
**Use Cases:**
- Low-level system programming where every instruction matters (e.g., bootloaders, kernel development).
- Performance-critical sections of code where fine-grained control is essential.
- Educational purposes to teach assembly language fundamentals.
2. Assembly Code Using Macros in MASM64**
Using macros in MASM64 allows you to define reusable blocks of code, simplify repetitive tasks, and introduce higher-level abstractions while still working in assembly.
**Advantages:**
- **Customization:** Macros allow you to create domain-specific abstractions tailored to your project's needs.
**Disadvantages:**
- **Complexity:** Overuse or poorly designed macros can make the code harder to understand, as the reader must trace through macro expansions to see the actual instructions.
- **Debugging Challenges:** Debugging macro-heavy code can be more difficult because the debugger shows the expanded code, which may not directly correspond to the original source.
- **Assembler Dependency:** Macros are specific to the assembler being used (in this case, MASM64), which can reduce portability if you switch to a different assembler.
3. **Which is More Professional?**
The term "professional" in this context can mean different things depending on the criteria:
**If the Goal is Clarity and Transparency:**
- Pure assembly code is often considered more professional because it leaves no room for ambiguity about what the code does. This is particularly important in scenarios like teaching, debugging, or collaborating with others who may not be familiar with the specific macros used.
**If the Goal is Portability:**
- Pure assembly code is generally more professional because it avoids dependencies on specific assembler features, making it easier to adapt to different environments.
**Recommendation**
- Use **pure assembly** for small, performance-critical sections where clarity and control are paramount.
For example, you might use macros to handle common tasks like function prologues/epilogues or register preservation, while keeping the core logic in pure assembly for transparency. :smiley:
You're trying to convince us to rely on the "judgment" of an "AI" thing to prove your pet theory that macros==bad?
Hah!
Now I don't like to use macros myself; however, I would never try to convince anyone else that using them is "unprofessional".
Case not proven.
include \masm32\MasmBasic\MasmBasic.inc
Init
Say "The purists never produce anything useful"
EndOfCode