Implementation of the COM interface FileOpenDialog

[Villuy]

just a some stupid ideology as I have seen.
No C for someone is best example?

I not understanded your remark. Just like previous one.

[NoCforMe]

I 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?

[TimoVJL]

Component Object Model

Unlike 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.

[satpro]

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.

[NoCforMe]

Sorry, not sorry.
Going to ignore your "advice".

[satpro]

Okay.

[Villuy]

I think the answer to that should be obvious:

Unlike 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.

[NoCforMe]

just 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 ...

[NoCforMe]

Interfaces are drug addict's thing in WinAPI. So probably yes.

??????? Please explain. You don't like interfaces?

[Villuy]

You don't like interfaces?

Interfaces seem inorganic, foreign matter in WinAPI.

[NoCforMe]

OK.

[six_L]

Using the macros(within UASM64) will become simpler.

Code Select Expand

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



[jorgon]

Nice, thanks for the post six_L

[ognil]

My five cents:  

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.

[NoCforMe]

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.