Azimut Project

[Vortex]

jdoe,

If it's possible, could you post here some Win64 import libraries? I would like to have a look at them.

[jdoe]

If it's possible, could you post here some Win64 import libraries? I would like to have a look at them.

Hi Vortex,

I finally found how I'm gonna do the protos for win64. Because of the nature of the calling convention on win64 and how the stack is used, the more adequate way IMHO is to write "externdef function:proc".
In the download sample below, I included dnsapi.inc for win32/win64 like it will appear in Azimut Project. Also included for you Vortex, dnsapi.lib from Vista SDK, in case you still want to give a look at it.



[attachment deleted by admin]

[jdoe]

Hi,

This project is not dead. I've been busy at work with pl/sql projects and I didn't had the spare time I would like.
I've been able lately to find time to write an installation program and add Windows 2008 to the package. The next step is to complete my h2inc program for adding constants and structures. The first version of Azimut include, for now, the import libraries and prototypes.


See first post for download link.

http://www.masm32.com/board/index.php?topic=7866.0

[jdoe]

Sorry the download link didn't worked few days because I had problem with my web hosting lately. I've reset all the settings so now everything is fine. I had in mind to change hosting but quit the idea for now. Maybe later.

New version of Azimut including the resource header file that is needed by the resource compiler when you use style constants for example. I don't think you will find something missing   :bdg

See first post for download link.

http://www.masm32.com/board/index.php?topic=7866.0

[jdoe]

Version 0.3 (Unicode support - TCHAR and String Macro)

With the TCHAR data type and the AzmtStr macro, you can build program like the example below and just comment or uncomment the UNICODE definition and the program is Unicode or not. Read the UNICODE.TXT from the README folder to be aware of some Unicode limitations.

Code Select Expand



.486
.MODEL FLAT,STDCALL
OPTION CASEMAP:NONE


UNICODE EQU 1


INCLUDE \AZIMUT\INCLUDE\AZIMUT.INC

INCLUDE \AZIMUT\INC32\kernel32.inc
INCLUDE \AZIMUT\INC32\user32.inc

INCLUDELIB \AZIMUT\LIB32\kernel32.lib
INCLUDELIB \AZIMUT\LIB32\user32.lib


.DATA

ALIGN 4
AzmtStr szTest1, TCHAR, <AzmtStr/0>
ALIGN 4
AzmtStr szTest2, TCHAR, <This is a >
AzmtStr        , TCHAR, <very >
AzmtStr        , TCHAR, <very >
AzmtStr        , TCHAR, <very >
AzmtStr        , TCHAR, <very >
AzmtStr        , TCHAR, <very >
AzmtStr        , TCHAR, <very >
AzmtStr        , TCHAR, <very >
AzmtStr        , TCHAR, <very >
AzmtStr        , TCHAR, <very >
AzmtStr        , TCHAR, <very >
AzmtStr        , TCHAR, <very >
AzmtStr        , TCHAR, <very long string/0>


.CODE

Main:

    invoke MessageBox, 0, addr szTest2, addr szTest1, 0

    invoke ExitProcess, 0

END Main




This will be the last release for a while. I'm working right now on the most important (constants and structures).

See first post for download link.

http://www.masm32.com/board/index.php?topic=7866.0

[jdoe]

I need opinions about a new way to do include files. To solve a little problem with UNICODE, I thought about doing them like below.
Appending a 'A' to the functions that are present with a 'W' for Unicode and no 'A' for ANSI version will make the UNICODE more reliable in the way that it will not be necessary to know those exceptions. When using a function with both ANSI and WIDE version it will be assumed that it needs a trailing A or W even though in facts, in the import library, there is not (like Process32First in kernel32).

Is there inconvenients I did not saw ?

Code Select Expand



EXTERNDEF _imp__Process32First@8:PTR PROTO_STDCALL_2
Process32FirstA EQU <_imp__Process32First@8>
EXTERNDEF _imp__Process32FirstW@8:PTR PROTO_STDCALL_2
Process32FirstW EQU <_imp__Process32FirstW@8>
EXTERNDEF _imp__Process32Next@8:PTR PROTO_STDCALL_2
Process32NextA EQU <_imp__Process32Next@8>
EXTERNDEF _imp__Process32NextW@8:PTR PROTO_STDCALL_2
Process32NextW EQU <_imp__Process32NextW@8>
EXTERNDEF _imp__ProcessIdToSessionId@8:PTR PROTO_STDCALL_2
ProcessIdToSessionId EQU <_imp__ProcessIdToSessionId@8>
EXTERNDEF _imp__PulseEvent@4:PTR PROTO_STDCALL_1
PulseEvent EQU <_imp__PulseEvent@4>

IFNDEF UNICODE
Process32First EQU <_imp__Process32First@8>
Process32Next EQU <_imp__Process32Next@8>
ELSE
Process32First EQU <_imp__Process32FirstW@8>
Process32Next EQU <_imp__Process32NextW@8>
ENDIF



[gwapo]

Hi jdoe,

Have you tried the H2INC utility of MASMv8 and up?
http://msdn.microsoft.com/en-us/library/aa903540(VS.71).aspx

I'm not sure if it's part of Visual Studio or not, but I found it in my VC++ installation.

Cheers,

-chris

[jdoe]

Have you tried the H2INC utility of MASMv8 and up?
http://msdn.microsoft.com/en-us/library/aa903540(VS.71).aspx

I'm not sure if it's part of Visual Studio or not, but I found it in my VC++ installation.

AFAIK, H2INC is an old tool that is not working anymore with recent Windows SDK/DDK header files.

[Vortex]

Hi jdoe,

You can try Japheth's h2incX tool :

About h2incx

This tool's purpose is to convert C header files to Masm-style include files. It is much more powerful than Microsoft's h2inc tool. The main purpose is to convert the Win32 include files, but it should work with any C header files as well. It is a simple Win32 console application, but a 32bit DOS extended binary version is included as well to be used on Non-Win32 platforms.

Features

    * a private profile file is used which allows fine-tuning of the include files to generate.
    * huge C header sets can be converted in one run (for example the Win32 headers contained in the PSDK).
    * prototypes may be written so the include file fits for both dynamic linking to a dll (using the IAT entries) and static linking to a library.
    * optionally a .DEF file is written, which can then be converted to an import library with POLIB.

http://japheth.de/h2incX.html

[jdoe]

My question has been misunderstood. I would like to know the advantage of both these methods of writing function protypes because they are encoded differently. Size speaking, the difference is obvious because it seems that one is not using a jump table, but how about speed or what else ?  I've put two different ouput from 2 disassembler.


INVOKE ExitProcess,  0



PROTO_STDCALL_1 TYPEDEF PROTO STDCALL :DWORD
EXTERNDEF _imp__ExitProcess@4:PTR PROTO_STDCALL_1
ExitProcess EQU <_imp__ExitProcess@4>

Code Select Expand



:00401000 6A00             PUSH 0
:00401002 FF1500204000     CALL DWORD PTR [00402000]
--------------------------------------------------------------------------
:00401000 6A00             PUSH 0
:00401002 FF1500204000     CALL DWORD PTR DS:[<&kernel32.ExitProcess>]




VERSUS


ExitProcess PROTO STDCALL a1:DWORD

Code Select Expand



:00401000 6A00             PUSH 00000000
:00401002 E801000000       CALL 00401008
:00401008 FF2500204000     JMP  DWORD PTR [00402000]
--------------------------------------------------------------------------
:00401000 6A00             PUSH 0
:00401002 E801000000       CALL <JMP.&kernel32.ExitProcess>
:00401008 FF2500204000     JMP  DWORD PTR DS:[<&kernel32.ExitProcess>