I have just added Greg Lyon's latest set of conversions from the MSVCRT dll and there is now a comprehensive set of conversion in both direcions for txt and numeric data. I have not yet had the time to document the new macros in the current help file but I have attached a text file that lists the names of the new conversions and the basics of how to use them.
[attachment deleted by admin]
FYI, seems there are some naming conflicts between Erol's latest msvcrt.inc and this latest version of macros.asm. (Can't find his thread.) I had to comment out many lines of his msvcrt.inc for it to compile properly. There must be 5 different versions of the msvcrt libs out there...
Hi Mark,
To avoid those naming conflicts, I created a cinvoke macro to call C functions. You can get the macro, library and the include file from :
http://www.vortex.masmcode.com/files/Dll2inc11.zip
My msvcrt library is extracted with polib from msvcrt.dll coming with Win Xp Home Sp2
Mark,
I think you should not comment out lines in an include file that is created directly from a DLL. It will cripple its functionality. You probably need to look at the problem from the other end, try renaming them.
Paul
Mark,
If you use Hutch's msvcrt.inc, the function names are prefixed with 'crt_' and there are no conflicts.
Vortex's msvcrt.inc uses the actual function names from the C Run-Time Library. As you noticed, there are several conflicts between the the CRT names and the MASM32 names.
That was the reason Hutch prefixed the names with 'crt_'. :bg
Quote from: Greg on August 30, 2005, 02:52:02 AM
If you use Hutch's msvcrt.inc, the function names are prefixed with 'crt_' and there are no conflicts.
Vortex's msvcrt.inc uses the actual function names from the C Run-Time Library. As you noticed, there are several conflicts between the the CRT names and the MASM32 names.
That was the reason Hutch prefixed the names with 'crt_'. :bg
That makes perfect sense, thanks Greg. ...Yet another perturbation in the tangled web of non-uniform assembler syntax. ::)
Vortex,
I didn't mean anything against what you are doing with msvcrt. It's just that what Hutch did was really a breakthrough in being able to use the msvcrt functions along with the MASM32 library.