Hello everyone,
I am working with Hutch's original 64 bit SDK. I have run into a problem which I can't solve. The original batch of Hutch includes is lacking two headers, winapifamily.inc and sdkddkver.inc. From Windows Kits 10 I was able to get a copy of each .h file. Using h2incx tool I was able to convert winapifamily.h lto its .inc relatie. Not so sdkddkver.inc. h2incx mangles some lines and the assembler fails.
So...
1. Is there a replacement for h2incx that I can obtain, or
2. Does Hutch's newer SDK contain include files that has the necessary .inc files?
Any suggestions are welcome!
regards,
Mark Allyn
Hi Mark,
Biterider translation:
https://github.com/ObjAsm/ObjAsm-C.2/blob/master/Code/Inc/Windows/sdkddkver.inc
Regards, HSE
Good evening HSE,
Thanks much! I would never have found this without your assistance.
Mark
Good morning HSE,
I attempted to assemble a trivial program now using Biterider's SDKDDKVER.INC. The command I use is:
ml64 /c mbox3.asm.
The following set of errors get kicked out:
undefined symbol :_MSC_VER
undefined symbol : Defined
invalid character in file (line 24)
cannot open file : excpt.inc
The last named error looks to me like there is another missing .inc in the original Hutch include file. I looked at line 24 and can't see anything wrong. _MSC_VER is a standard macro that the OS should know, I think. BTW I am running on a Win 11 box.
Regards,
Mark Allyn
Hi Mark,
I don't know about _MSC_VER..
But from the link that HSE gave you, you can see other include files including excpt.inc
https://github.com/ObjAsm/ObjAsm-C.2/blob/master/Code/Inc/Windows (https://github.com/ObjAsm/ObjAsm-C.2/blob/master/Code/Inc/Windows)
It might help if you tell us about your programming environment. What editor or IDE are you using? What assembler and linker versions?
Could you post or attach your source code?
HSE and Zedd:
I wrote a little c program to see if my Win 11 box knows what to do with _MSC_VER. It does indeed know. The pgm prints out 1930 which is the correct version number.
The specific print statement is:
printf("The version number is %d\n", _MSC_VER);
Regards,
Mark Allyn
Quote from: markallyn on June 18, 2023, 10:18:29 PM
undefined symbol :_MSC_VER
Knowing it now, you can try
_MSC_VER=1930 in your assembly code, to "solve" that error...
Quotecannot open file : excpt.inc
... but most likely other errors will pop up because an entire file is missing.
Quote_MSC_VER is a standard macro
It's a simple equate of the form
_MSC_VER equ 1930 or
_MSC_VER=1930. They serve to decide which "code branch" to take; check what it does inside the include files. Typically, you'll find something like
if _MSC_VER ge 1900
mov eax, 123 ; just an example
else
mov eax, 456
endifHere is a selection from WinNT.h:
#if _MSC_VER >= 1200/#pragma warning(push)
#if _MSC_VER >= 1300/#define TYPE_ALIGNMENT( t ) __alignof(t)
#if (_MSC_VER >= 1200) && !defined(MIDL_PASS)/#define DECLSPEC_NORETURN __declspec
#if (_MSC_VER >= 1200) && !defined(MIDL_PASS)/#define DECLSPEC_NOTHROW __declspec(
#if (_MSC_VER >= 1300) && !defined(MIDL_PASS)/#define DECLSPEC_ALIGN(x) __declspec
#if (_MSC_VER >= 1100) && defined (__cplusplus)/#define DECLSPEC_UUID(x) __declsp
#if (_MSC_VER >= 1100) && defined(__cplusplus)/#define DECLSPEC_NOVTABLE __declspe
#if (_MSC_VER >= 1100)/#define DECLSPEC_SELECTANY __declspec(selectany)
#if (_MSC_VER >= 1210)/#define NOP_FUNCTION __noop
#if (_MSC_VER >= 1200) && (defined(_M_ALPHA) || defined(_M_AXP64))/#define DECLSPEC_
#if (_MSC_VER >= 1300)/#define DECLSPEC_NOINLINE __declspec(noinline)
#if (_MSC_VER >= 1200)/#define FORCEINLINE __forceinline
#if (_MSC_VER >= 1300) && !defined(MIDL_PASS)/#define DECLSPEC_DEPRECATED __declsp
#if (_MSC_VER >= 800) || defined(_STDCALL_SUPPORTED)/#define NTAPI __stdcall
#if 0 && (_MSC_VER > 1000)/#define DECLARE_HANDLE(name) struct name##__; typedef str
#if _MSC_VER >= 1200/#pragma warning(push)
#if _MSC_VER >= 1200/#pragma warning(pop)
#if _MSC_VER >= 1300/#define RotateLeft32 _rotl
#endif /* _MSC_VER >= 1300 *//#ifdef __cplusplus
#if (_MSC_VER > 1200)/#define DEFAULT_UNREACHABLE default: __assume(0)
#if _MSC_VER >= 1200/#pragma warning(push)
#if _MSC_VER >= 1200/#pragma warning(pop)
#if (_MSC_FULL_VER >= 140040816) || (defined(_PREFAST_) && (_MSC_VER >= 1400))/#def
#if _MSC_VER >= 1200/#pragma warning(push)
#if _MSC_VER >= 1200/#pragma warning(pop)
#if (_MSC_VER >= 1400)/#define UnsignedMultiply128 _umul128
#if _MSC_VER >= 1200/#pragma warning(push)
#if _MSC_VER >= 1200/#pragma warning(pop)
#if _MSC_VER >= 1200/#pragma warning(push)
#if _MSC_VER >= 1200/#pragma warning(pop)
#if _MSC_VER >= 1200/#pragma warning(pop)
It's also used in some Masm32 headers, see below.
I cheated little. And asked ChatGPT
QuoteWhich Windows API header contains _MSC_VER define?
And AI answered....
QuoteThe _MSC_VER define is not contained in a specific Windows API header. It is actually a preprocessor macro defined by the Microsoft C/C++ compiler (MSVC) to indicate the version of the compiler being used.
The _MSC_VER define is typically used to conditionally compile code based on the version of the MSVC compiler. It is often used in combination with other defines, such as _WIN32 or _WIN64, to conditionally include or exclude specific sections of code based on the target platform and compiler version.
To use _MSC_VER in your code, you can include the <Windows.h> header file, which is a common header for Windows API programming. However, note that _MSC_VER is not specific to Windows API headers and can be used in any C or C++ code compiled with MSVC.
I'm using Visual Studio as my IDE, and it gets usually newer version on every patch tuesday.
Hi Mark,
Quote from: markallyn on June 18, 2023, 11:21:57 PM
to see if my Win 11 box knows what to do with _MSC_VER. It does indeed know.
ObjAsm includes are a full set, then could be not totally interchangable with Masm64 SDK. They are newer and conserve more of the complexity for a compiler. Then some includes are a problem for ML64, because that. That set work perfectly with UASM32 and UASM64 (and laters JWASM 15 and 16,IIRC).
Obviously if you need to adapt an include for ML64, is very easier from Biterider's ones than from originals.
Regards, HSE
Quote from: C3 on June 18, 2023, 11:36:04 PM
it gets usually newer version on every patch tuesday.
:rolleyes: That doesn't inspire confidence, and it is quite unappealing. :tongue:
Anyway, I am 'assuming' the OP is using VisualStudio IDE as well?
Quote from: HSE on June 18, 2023, 11:49:31 PM
Obviously if you need to adapt an include for ML64, is very easier from Biterider's ones than from originals.
Regards, HSE
Sound advice. Most likely some includes will need to be manually tweaked.
Quote from: zedd151 on June 18, 2023, 11:50:36 PM
Sound advice.
:biggrin: :biggrin: ChatHSE, the true AI (Amazing Ignorance)
The _MSC_VER equate (it's an equate, not a macro) intrigued me, so I investigated a bit.
There is no
#define _MSC_VER in any of the VC header files. The reason is that the compiler itself defines the equate, invisible to the programmer:
QuoteOzkan Sezer - 2012-04-03 (https://sourceforge.net/p/mingw-w64/bugs/282/)
_MSC_VER is defined by MS Visual C compiler to identify itself. You aren't supposed to define _MSC_VER by yourself, and most definitely not when using gcc.
So
you are free to define it in Assembly code as you like, or, more precisely, according to what kind of code you want to use in your programs. Check the various
if (_MSC_VER ge nnnn) paragraphs, example from \Masm32\include\DX9Includes\d3dx9.inc:
if (_MSC_VER ge 1200)
D3DXINLINE equ __forceinline
else
D3DXINLINE equ __inline
endif
QuoteThe _MSC_VER equate (it's an equate, not a macro) intrigued me, so I investigated a bit.
There is no #define _MSC_VER in any of the VC header files. The reason is that the compiler itself defines the equate, invisible to the programmer:
I tried to find it from the C++ header files, and there isn't none (only if..endif, to choose branching). Looks like its a internal macro for the C++ compiler where it states what version it is, allowing conditional compiling.
Quote from: jj2007 on June 19, 2023, 09:11:14 PM
There is no #define _MSC_VER in any of the VC header files. The reason is that the compiler itself defines the equate, invisible to the programmer:
:thumbsup:
I read just some days ago that there is some problems because VS select things of compilation environment. Some programs can fail in a different environment. No paid to much attention :biggrin:
In Biterider's includes _MSC_VER is defined:
_MSC_VER equ 1900 ;Major & minor number of C compiler's version number
_MSC_FULL_VER equ 190024210
https://github.com/ObjAsm/ObjAsm-C.2/blob/master/Code/Inc/Windows/WinAsm.inc#L213
_MSC_VER raises its ugly head also in some Masm32 include files, for example in \Masm32\include\DX9Includes\d3dx9.inc:
ifndef D3DXINLINE
ifdef _MSC_VER
if (_MSC_VER ge 1200)
D3DXINLINE equ __forceinline
else
D3DXINLINE equ __inline
endif
else
ifdef __cplusplus
D3DXINLINE equ inline
else
D3DXINLINE equ 1
endif
endif
endif
Now the odd thing is that these are the only lines where D3DXINLINE shows up. In other words: it's never being used. It is a conversion artefact. C/C++ programmers may have a use for it (inlining yes or know?), Assembly programmers don't.
For comparison, check BaseTsd.INC (no idea where I got that from, maybe this post by ToutEnMasm (http://masm32.com/board/index.php?topic=576.msg96680#msg96680) - it's not a Masm32 include):
if 0 eq defined(_MAC) AND (defined(_M_MRX000) OR defined(_M_AMD64) OR defined(_M_IA64)) AND (_MSC_VER ge 1100) AND 0 eq (defined(MIDL_PASS) OR defined(RC_INVOKED))
All I can say after reading all this is that I am so glad I'm never going to use 64-bit assembly language!
Quote from: NoCforMe on June 20, 2023, 05:47:18 AM
All I can say after reading all this is that I am so glad I'm never going to use 64-bit assembly language!
:biggrin: :biggrin: 32 and 64 bits are same includes! And they are updated with new Win versions.
Fortunately, old include files still allow to use enough system resources to make interesting programs.
This is probably why I can't get direct2d to work with plain old ml64. But i have no problem with Direct2d in Visual Studio 64 bit
Quote from: BugCatcher on June 22, 2023, 02:17:22 AM
This is probably why I can't get direct2d to work with plain old ml64
Perhaps we could find out together. Do you have a short assembly source where it fails?