Hello,
I try (labouriosly) to build the m64lib.
GDIP_Save_Bmp could'nt find GdipBitmapConvertFormat used two times.
It's not in gdiflat.h
Where is this proc ?
Find the prototype in gdiplus flat and build the library
GdipBitmapConvertFormat PROTO pInputBitmap:QWORD ,format:DWORD ,dithertype:DWORD ,palettetype:DWORD ,palette:QWORD ,alphaThresholdPercent:REAL4
Building the images.asm
Quote
Images.obj : error LNK2019: symbole externe non résolu Gdip_Save_PNG référencé dans la fonction save_PNG_image
Images.obj : error LNK2019: symbole externe non résolu __imp__atoi64 référencé dans la fonction jpgdlg
Images.obj : error LNK2019: symbole externe non résolu __imp__i64toa référencé dans la fonction jpgdlg
Images.exe : fatal error LNK1120: 3 externes non résolus
Two files need a prototype
Gdip_Save_PNG and GDIP_Save_Bmp
Now I miss two sources:
atoi64
i64toa
Yves, the procedures build correctly with the supplied include files and libraries, are you using something different ?
I use the original source.
and use the provided batch with PATH,INCLUDE and LIB
Quote
@echo off
set appname=Images
set PATH=
set PATH=C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\Hostx64\x64;C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin;C:\Program Files (x86)\Windows Kits\8.1\bin\x64
set INCLUDE=c:\install64\include64;c:\install64\macros64;c:\install64\m64lib
set LIB=C:\Program Files (x86)\Windows Kits\10\Lib\10.0.17763.0\um\x64;C:\Program Files (x86)\Windows Kits\10\Lib\10.0.17763.0\ucrt\x64;C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\lib\x64;H:\masm32\m64lib
if exist %1.obj del %appname%.obj
if exist %1.exe del %appname%.exe
rc.exe rsrc.rc
ml64.exe /c /nologo %appname%.asm > error.txt
link.exe /SUBSYSTEM:WINDOWS /ENTRY:entry_point /LARGEADDRESSAWARE %appname%.obj rsrc.res >> error.txt
dir %appname%.*
pause
Doing this ,you need to delet all the path in the include files. (not a real problem)
I had need to update the donwload
To made corrections to the two files.
need also to add "includelib C:\install64\lib64\msvcrt.lib "
That's all for today,it is compiled
Yves,
64 bit MASM does not use prototypes. The following is probably something you would use with UASM.
GdipBitmapConvertFormat PROTO pInputBitmap:QWORD ,format:DWORD ,dithertype:DWORD ,palettetype:DWORD ,palette:QWORD ,alphaThresholdPercent:REAL4
This is the valid MASM version.
externdef __imp_GdipBitmapConvertFormat:PPROC
GdipBitmapConvertFormat equ <__imp_GdipBitmapConvertFormat>
Quote from: TouEnMasm on July 02, 2020, 07:46:02 AM
Doing this ,you need to delet all the path in the include files. (not a real problem)
It becomes a real problem for everybody who does not use exactly the same tools and the same environmental variables. In other words: you'll get the usual C/C++ mess
Quoteneed also to add "includelib C:\install64\lib64\msvcrt.lib "
Once upon a time we learnt that not everybody hosts Masm32 on drive C:, and that therefore it was a good idea to use \install64\lib64\msvcrt.lib without the drive letter :cool:
JJ,
Happy to know that C/C++ is a mess (?) :badgrin:
The ful path is here to Distinguish the msvcrt microsoft from the msvcrt of the forum
Yves,
While there is little point in trying to replace the 64 bit MASM include files and libraries, the UASM folks desperately need a decent set of viable include files and as you have done extensive work in a format that would work for UASM in 64 bit, this may be a good target for your work.
I did a simple test using UASM with a quickly modified form of the 32 bit MASM include files by renaming the DWORD with PTR and it worked fine in 64 bit.
If you can post your little sample,I will study what can be done for that.
Yves, I have attached a zip file that has a quickly modified 32 bit MASM include file where I changed the DWORD to PTR which works OK with UASM.
Its format is as follows.
CDefFolderMenu_Create2 PROTO :PTR,:PTR,:PTR,:PTR,:PTR,:PTR,:PTR,:PTR,:PTR
CDefFolderMenu_Create PROTO :PTR,:PTR,:PTR,:PTR,:PTR,:PTR,:PTR,:PTR,:PTR
CallCPLEntry16 PROTO :PTR,:PTR,:PTR,:PTR,:PTR,:PTR
CheckEscapesA PROTO :PTR,:PTR
IFNDEF __UNICODE__
CheckEscapes equ <CheckEscapesA>
ENDIF
CheckEscapesW PROTO :PTR,:PTR
IFDEF __UNICODE__
CheckEscapes equ <CheckEscapesW>
ENDIF
CommandLineToArgvW PROTO :PTR,:PTR
IFDEF __UNICODE__
CommandLineToArgv equ <CommandLineToArgvW>
ENDIF
I have also posted the source file but there is too much to get it going as I used bits from all over my dev drive including a lot of MASM stuff so its not buildable. If you can produce an include file of this type it will make UASM a lot more usable as its main weakness has been lousy support and very poor include files.
If i understand well , you want than I take all the includes in masm32\include and that i change :DWORD by :PTR in all files ?
I don't see the attachment ?
You have done it here:
--------link destroy ------
search your name
No, that's easy to do, what I had in mind was your own includes for win64 would be useful to the folks who want to use UASM.
Quote from: hutch-- on July 03, 2020, 07:17:56 AM
No, that's easy to do, what I had in mind was your own includes for win64 would be useful to the folks who want to use UASM.
There is a set of includes and libraries for UASM. Biterider maked that for ObjAsm.
Quote
No, that's easy to do, what I had in mind was your own includes for win64 would be useful to the folks who want to use UASM.
Here,I am a little lost.
I have re-compiled my IDE (32) with my headers and with UASM without a problem.
For 64 bits ,I have made further little prog using UASM and my headers without a problem.
With my headers,to use UASM ,You need to download the package and include the SDK64.inc ,That's all.
Where is the problem ?
To be more clear,here is a sample using my headers http://luce.yves.pagesperso-orange.fr/header.htm (http://luce.yves.pagesperso-orange.fr/header.htm)
I have re-took the messagebox 64 bits provided by UASM and added a messagebox using the headers
As i say,you add "include sdk64.inc" and all is done.
You can put in comment the useless things (externdef ...)
ML64 is like a dinosaure if we compare it with UASM.
What is simple to use,must stay simple.
:biggrin:
Quote
ML64 is like a dinosaure if we compare it with UASM.
What is simple to use,must stay simple.
Sure is, that's why I use it, clean, simple and reliable.
in 64 bits
The new crt need to add some defines.
The ucrt and msvcrt lib must be include
the EXTRN __imp__i64toa:PROC is in use instead of _i64toa
_i64toa equ <__imp__i64toa> create a symbol redifinition with _i64toa PROTO cproto :QWORD ,:XMASM ,:DWORD
any idea to contnue using the invoke ?
In MASM I use the following.
externdef __imp__i64toa:PPROC
vc__i64toa equ <__imp__i64toa>
Unless you use a consistent prefix, you get naming conflicts. The above works perfectly.
The msvcrt.inc(64) work ,it's good
It use the original msvcrt.dll,It's good
It allow functions to have any number of arguments,it's no good.
Is there a way to use a dynamic load of the functions ?.
and now the simple way to use the new CRT with UASM and the translated SDK.
You need only the two crt libraries who allow you to link statically with the New CRT and the OPTION PROC:NONE.
THAT'S ALL
The sample convert 500h in radix(base) 10
As you use the translated SDK,you are prompted in case of syntax errors