Recent Posts

Pages: [1] 2 3 ... 10
1
Oh sorry my brain is still half on holiday.. if it's specifying a RETURN type then yes there's no colon before the type. For a normal PROC definition there would also not be a comma in front, but you're right in this case for CVIRTUAL (or any of those oo macros).. I'll check it out.

I've fixed the ->Release() , there was a bug in the macro for the de-referencing logic.

Edit: On checking, I have only implemented basic primitive types for return... I will add support for traversing an ID type to get it's final type too :)
2
I also noticed you aligned rsp manually in main proc, that shouldn't be necessary ? if it's a proc it should align, as long as it's not some plain label entry point like main:
You are right, I was using the 7th January release, not the one of 8th January.

Quote
So you should be able to use the normal OO methods like:

_VINVOKE direct3d, GetDeviceCaps, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, ADDR caps
_VINVOKE direct3d, Release
I will check that out, when possible.  :t

Quote
Isn't this missing a colon : before the type ?

Code: [Select]
CVIRTUAL SetPrivateData, :HRESULT, :PTR, :DWORD, :PTR
No, it is as you say in the uasm246_ext.pdf:

COMINTERFACE IDirect3D9
      CVIRTUAL RegisterSoftwareDevice, DWORD, :PTR
      CVIRTUAL GetAdapterCount, DWORD
.....
ENDCOMINTERFACE
No colons before the type.  ::)


3
MasmBasic & the RichMasm IDE / RichMasm beta with bubble help for WinAPI
« Last post by jj2007 on January 17, 2018, 09:48:50 PM »
This beta has a brand new feature, provided that you download this archive and extract the only file as \Masm32\MasmBasic\Res\ApiAll.jno.

From the attached archive, unzip:
- \Masm32\MasmBasic\RichMasm.exe
- \Masm32\MasmBasic\Res\menusRM.ini

Then drag one of your sources over RichMasm.exe and check what you see when hovering over, for example, over CreateWindowEx. If it doesn't look as in the screenshot below, please let me know 8)

The ApiAll.jno database has over 10,000 entries. There is a certain risk that it contains strings that have another meaning in your code. Let me know if you see a mismatch. The search is done as follows:

  mov esi, ApiAll$              ; esi is the database, edi the API to be found
  .if !Instr_(esi, edi, 4)
        .if ecx>6                       ; find createwindow but not pop or addr
                .if !Instr_(esi, edi, 5)        ; if case-sensitive not found, try case-insensitive full word
                    void Instr_(esi, edi, 1)    ; if even that failed, try a simple case-insensitive search
                .endif
        .endif
  .endif
  .if eax
       ; deb 4, "Api match", $eax:20


Note that by right-clicking on a selected word, e.g. LoadCursor, there is an entry in the popup menu called "Insert tooltip text".

4
UASM Assembler Development / Re: How to release the COM interfaces (64-bit)?
« Last post by johnsa on January 17, 2018, 09:12:08 PM »
Found the issue and fixing it now.

I also noticed you aligned rsp manually in main proc, that shouldn't be necessary ? if it's a proc it should align, as long as it's not some plain label entry point like main:

5
UASM Assembler Development / Re: How to release the COM interfaces (64-bit)?
« Last post by johnsa on January 17, 2018, 09:01:39 PM »
Example using the macro version would be:

Code: [Select]

mov direct3d,Direct3DCreate9( D3D_SDK_VERSION )
.if( rax != 0 )
_VINVOKE direct3d, IDirect3D9, GetDeviceCaps, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, ADDR caps
_VINVOKE direct3d, IDirect3D9, Release
.endif


Looking at the -> release issue.
6
UASM Assembler Development / Re: How to release the COM interfaces (64-bit)?
« Last post by johnsa on January 17, 2018, 08:39:44 PM »
Hi,

With the Jan 8th update, the documentation was updated to reflect the change to how the OO stuff is handled internally. OO objects are now mapped the same way as COM objects in the following way:

Before:
COM instance = [pvtbl,instance values]
OO instance   = [method ptr1, method ptr 2....., instance values]

So before the OO objects were extremely memory inefficient. For example if we created a Vec3 object, we'd have 16 bytes of actual instance data, but potentially 100 or more bytes in method pointers per instance.
So to remedy this I adapted the OO system to work as the COM does using just a vTbl pointer and fields per instance, so a 16 byte Vec3 instance may use 24 or 32 bytes at most depending on alignment.

With this in place the two specific COM invocation macros _VCOM, _VCOMINVOKE were no longer necessary so I removed them as the COM objects can just use the normal invocations.
So you should be able to use the normal OO methods like:

_VINVOKE direct3d, GetDeviceCaps, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, ADDR caps
_VINVOKE direct3d, Release

You are right however about Release, it's built-in to the COMINTERFACE type so I would expect it to not allow you to add it manually, you could always use a CSTRUCT type instead if you wanted to add the generic COM methods yourself. For some reason Release() isn't work which I will investigate right now.

For the wide string example you can prefix the string literal with L"" , so this should work:
INVOKE wprintf, L"\nDXGI Adapter: %u\nDescription: %s\n",r12d, addr [desc].Description
But there's nothing wrong with using cstr and wstr as always, sometimes I prefer it being able to separate out the individual characters for formatting etc like 10, 9 etc..

Your arrow operator uses the register r15 without preserving it. This will not be OK if you are working with ASM modules instead of standalone ASM applications.
I had thought about this, I didn't want to needlessly add a preservation around the call itself as the main application is to use it from ASM directly. I would think if you're calling from a module the wrapper function should preserve R15 in the USES clause. I'm happy to hear ideas on this.

Another thing:
Why can't I use HRESULT even if I typedef it in cases like this:

Code: [Select]
CVIRTUAL SetPrivateData, HRESULT, :PTR, :DWORD, :PTR
Isn't this missing a colon : before the type ?

Code: [Select]
CVIRTUAL SetPrivateData, :HRESULT, :PTR, :DWORD, :PTR
7
The Campus / Re: GetOpenFileName Hook
« Last post by six_L on January 17, 2018, 12:06:19 PM »
hi,jj2007
tested again, the cDialogHook_2.exe can extract 32 and 64 bit dll or exe ICO.
attachment: there are some icons in win explorer.exe file.
8
Easy Code IDE 32/64-bit / Re: Tab text illegible.
« Last post by AssemblyChallenge on January 17, 2018, 12:05:38 PM »
Those are working beautifully. Just for completeness, you can reproduce the bug in Windows 7 if you set the Visual Effects to "Adjust for best performance" in Computer Properties.
9
PowerBASIC / Re: PowerBasic assembler
« Last post by Crupib on January 17, 2018, 12:03:44 PM »
Thanks I was able to get i5 to work with the offset instruction
10
MASM32 / Re: QE Run Program
« Last post by felipe on January 17, 2018, 05:07:01 AM »
Maybe it's using an old trick and executing the program through a cmd command? :idea:
I have tried winexec in win 8.1 and works just fine.  :bgrin:
Pages: [1] 2 3 ... 10