News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Calling imported functions

Started by Darmani, December 23, 2010, 06:18:37 AM

Previous topic - Next topic

japheth

To answer the OP's question:

Quote from: Darmani on December 23, 2010, 06:18:37 AM
I have something of an understanding of what this means, but, after rereading several chapters in the MASM Programmer's Guide, no idea why it's occuring or how to fix it. I've been stuck on this for two days! Help would be appreciated.

the problem is the "assume cs". With model FLAT, you're forced to a non-segmented memory model. So either remove the assume or change it to "assume cs:FLAT".


.686p
.model flat
OPTION LANGUAGE:C

include advapi32.inc
includelib advapi32.lib

_text segment para public 'CODE' use32
assume cs:FLAT

_start proc near
call RegCreateKey
_start endp

_text ends

_data segment para public 'DATA' use32
assume cs:_data
_data ends

end  _start


hutch--

 :bg

> It's just a bit old-fashioned with its "all's a DWORD"-philosophy.

Well, I wonder what is modern, 16 bit segmented architecture ? Now i am a barbarian, I would be happy with 64 bit long mode where all are QWORD but 64 bit code is still poorly supported at the OS level at the moment. 32 bit will be with us for some time yet and it benefits from a 64 bit OS (win7 64) in terms of memory allocation, particularly with IPC extending the amount of data that can be manipulated.

As far as C/C++ equates that all collapse back to DWORD, I never did see the point when you can remove at least one level of confusion by sticking to assembler data sizes.
Download site for MASM32      New MASM Forum
https://masm32.com          https://masm32.com/board/index.php

jj2007

Quote from: japheth on December 23, 2010, 10:58:06 AM
It's just a bit old-fashioned with its "all's a DWORD"-philosophy. :toothy

Being more specific would only make sense if the assembler did a proper type checking. Since it doesn't, DWORDs are just fine for me :bg
Also, in a HLL you could stop a user from passing a string pointer where the proc expects a handle; in assembler, the passed variable will often be in a register, not a variable with a clearly defined type.

include \masm32\include\masm32rt.inc

MyTest PROTO: DWORD, :HANDLE

.code
AppName db "Masm32 is great!", 0
Hello db "A message:", 0

start:
invoke MyTest, offset AppName, addr Hello
exit

MyTest proc arg1, arg2:DWORD
  MsgBox 0, arg1, arg2, MB_OK
  ret
MyTest endp

end start