Hello everyone,
I'm currently writing a program in Win64 assembly language with the intention of using the StringCchCat function to concatenate two strings. However, I'm encountering the following error during compilation:
tststr.obj : error LNK2019: unresolved external symbol StringCchCat referenced in function main
tststr.exe : fatal error LNK1120: 1 unresolved externalsIt seems like StringCchCat cannot be located. I would like to ask:
Do I need to manually link to a specific .lib file?
Are there any particular settings required for using this function in assembly?
Thank you very much for any advice!
My source is tststr.asm:
INCLUDE \masm64\include64\masm64rt.inc
StringCchCat PROTO :QWORD,:DWORD,:QWORD
.DATA
hInst DQ ?
szTitle DB "Test StringCb"
str1 DB "I learn ",40h DUP (0)
str2 DB "assembly language.",0
.CODE
main PROC
invoke StringCchCat,ADDR str1,SIZEOF str1,ADDR str2
invoke MessageBox,0,ADDR str1,ADDR szTitle,MB_OK
call ExitProcess
main ENDP
END
You can search in /include64 files.
Probably equate of import is vc_StringCchCat.
It's a C macro:
STRSAFEAPI
StringCchCatA(
_Inout_updates_(cchDest) _Always_(_Post_z_) STRSAFE_LPSTR pszDest,
_In_ size_t cchDest,
_In_ STRSAFE_LPCSTR pszSrc)
{
HRESULT hr;
size_t cchDestLength;
hr = StringValidateDestAndLengthA(pszDest,
cchDest,
&cchDestLength,
STRSAFE_MAX_CCH);
if (SUCCEEDED(hr))
{
hr = StringCopyWorkerA(pszDest + cchDestLength,
cchDest - cchDestLength,
NULL,
pszSrc,
STRSAFE_MAX_LENGTH);
}
return hr;
}
Worker functions are in strsafe.lib
pFile Data Description Value
00000044 00000019 Number of Symbols
00000048 000006B2 Offset to Header StringVPrintf_lWorkerA
0000004C 000006B2 Offset to Header StringVPrintf_lWorkerW
00000050 00003E08 Offset to Header ??_C@_00CNPNBAHC@?$AA@
00000054 00003E08 Offset to Header ??_C@_11LOCGONAA@?$AA?$AA@
00000058 00003E08 Offset to Header StringCopyWorkerA
0000005C 00003E08 Offset to Header StringCopyWorkerW
00000060 00003E08 Offset to Header StringExHandleFillBehindNullA
00000064 00003E08 Offset to Header StringExHandleFillBehindNullW
00000068 00003E08 Offset to Header StringExHandleOtherFlagsA
0000006C 00003E08 Offset to Header StringExHandleOtherFlagsW
00000070 00003E08 Offset to Header StringExValidateDestA
00000074 00003E08 Offset to Header StringExValidateDestAndLengthA
00000078 00003E08 Offset to Header StringExValidateDestAndLengthW
0000007C 00003E08 Offset to Header StringExValidateDestW
00000080 00003E08 Offset to Header StringExValidateSrcA
00000084 00003E08 Offset to Header StringExValidateSrcW
00000088 00003E08 Offset to Header StringLengthWorkerA
0000008C 00003E08 Offset to Header StringLengthWorkerW
00000090 00003E08 Offset to Header StringVPrintfWorkerA
00000094 00003E08 Offset to Header StringVPrintfWorkerW
00000098 00003E08 Offset to Header StringValidateDestA
0000009C 00003E08 Offset to Header StringValidateDestAndLengthA
000000A0 00003E08 Offset to Header StringValidateDestAndLengthW
000000A4 00003E08 Offset to Header StringValidateDestW
000000A8 00003E08 Offset to Header UnalignedStringLengthWorkerW
Thank you, HSE and TimoVJL, for your response.
I couldn't find strsafe.lib in masm64\lib64. Where can I download it?
QuoteI couldn't find strsafe.lib in masm64\lib64
No neither could I,.. I have searched our server and We do Not have a copy of it anywhere,... Should We ??? :undecided:
It certainly Isn't in the copies of MASM64 or the SDK ??
Quote from: wanker742126 on October 30, 2024, 11:41:12 PMThank you, HSE and TimoVJL, for your response.
I couldn't find strsafe.lib in masm64\lib64. Where can I download it?
from Windows SDK
Quotefrom Windows SDK
Yeah ??? ... Which Windows SDK Timo ???
It's NOT anywhere in the copy of MASM64 We have on the server ??
Quote from: stoo23 on October 31, 2024, 12:20:29 AMQuoteI couldn't find strsafe.lib in masm64\lib64
No neither could I,.. I have searched our server and We do Not have a copy of it anywhere,... Should We ???
Stoo, the Windows SDK (software development kit) is a Microsoft product, which has a set of its own libraries (*.lib files). Hence are a separate entity from the Masm64 SDK that we offer. I don't think we should duplicate it within the Masm64 SDK.
This is another example of why it is difficult for some users to use Visual Studio with Masm32 SDK and/or Masm64 SDK.
They have the impression that Masm64 SDK has libraries and include files that it simply does not, but are either in the Visual Studio package or in one of the Microsoft Windows SDK's. (Microsoft products)
I do agree however that the Masm64 SDK is missing some
include files (*.inc) that it should have - plus some incomplete or erroneous include files, which should not be confused with Microsofts own include files (*.h) which either the Visual Studio package or one of the Windows SDK packages does have.
:smiley:
Quote from: stoo23 on October 31, 2024, 12:51:39 AMQuotefrom Windows SDK
Yeah ??? ... Which Windows SDK Timo ???
It's NOT anywhere in the copy of MASM64 We have on the server ??
Google gives this: Microsoft Windows SDK (https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/)
Also included in Microsoft Visual Studio, one reason to use, for me.
Quote from: zedd151 on October 31, 2024, 01:00:26 AMQuoteI do agree however that the Masm64 SDK is missing some include files (*.inc) that it should have - plus some incomplete or erroneous include files, which should not be confused with Microsofts own include files (*.h) which either the Visual Studio package or one of the Windows SDK packages does have.
Thats what is really needed. I just add stuff from Microsoft headers (*.h) to include files (*.inc) when I need something what is not already there.
Thanks for the Above link and info' guys :thumbsup:
I'll try and Place that Windows resource somewhere usefully appropriate :wink2: :thumbsup: Perhaps in the
Reference section :smiley:
QuoteStoo, the Windows SDK (software development kit) is a Microsoft product, which has a set of its own libraries (*.lib files). Hence are a separate entity from the Masm64 SDK that we offer. I don't think we should duplicate it within the Masm64 SDK.
Yep understood, I was just commenting on the fact that We did not have a copy of that file Anywhere on our server, OR in the Files I have locally from Hutch.
As suggested, thanks for the info' :azn:
Don't pay attention to files names, just search function name.
strsafe.h
Quote from: BugCatcher on October 31, 2024, 03:56:45 AMstrsafe.h
MS documents don't always tell whole truth, so we had to give additional info.
Hello wanker742126,
You don't have to download a lot of files to obtain the header file strsafe.h, it comes with Pelles C :
\PellesC\Include\strsafe.h
STRSAFEAPI StringCchCatA(STRSAFE_LPSTR pszDest, size_t cchDest, STRSAFE_LPCSTR pszSrc)
{
size_t cchDestLength;
HRESULT hr = _StringValidateDestAndLengthA(pszDest, cchDest, &cchDestLength, STRSAFE_MAX_CCH);
if (SUCCEEDED(hr)) {
hr = _StringCopyWorkerA(pszDest + cchDestLength, cchDest - cchDestLength, NULL, pszSrc, STRSAFE_MAX_LENGTH);
}
return hr;
}
STRSAFEWORKERAPI _StringCopyWorkerA(STRSAFE_LPSTR pszDest, size_t cchDest, size_t * pcchNewDestLength, STRSAFE_PCNZCH pszSrc, size_t cchToCopy) {
HRESULT hr = S_OK;
size_t cchNewDestLength = 0;
while (cchDest && cchToCopy && (*pszSrc != '\0')) {
*pszDest++ = *pszSrc++;
cchDest--;
cchToCopy--;
cchNewDestLength++;
}
if (cchDest == 0) {
pszDest--;
cchNewDestLength--;
hr = STRSAFE_E_INSUFFICIENT_BUFFER;
}
*pszDest = '\0';
if (pcchNewDestLength) {
*pcchNewDestLength = cchNewDestLength;
}
return hr;
}
Obtaining Pelles C :
http://www.smorgasbordet.com/pellesc/download.htm (http://www.smorgasbordet.com/pellesc/download.htm)
Hi everyone, thanks for your help, I finally solved this problem.
I followed TimoVJL's advice and downloaded the Windows SDK from the link provided by C3, then installed it.
The strsafe.lib file was located in the
C:\Program Files (x86)\Windows Kits\10\Lib\10.0.26100.0\um\x64 folder. However, it's not an import library, and I took quite a detour before realizing this.
Using DUMPBIN /ALL, I discovered that StringCchCatA was not present in the library. After reading the contents of strsafe.h provided by TimoVJL, Vortex and the file located at
C:\Program Files (x86)\Windows Kits\10\Include\10.0.26100.0\shared\strsafe.h, I realized StringCchCatA is not included in strsafe.lib. It's more like a macro, so I wrote one using assembly language syntax. Here's the source file :
INCLUDE \masm64\include64\masm64rt.inc
includelib "c:\Program Files (x86)\Windows Kits\10\Lib\10.0.26100.0\um\x64\strsafe.lib"
STRSAFE_MAX_CCH EQU 2147483647
STRSAFE_MAX_LENGTH EQU STRSAFE_MAX_CCH-1
StringValidateDestAndLengthA PROTO :QWORD,:DWORD,:QWORD,:DWORD
StringCopyWorkerA PROTO :QWORD,:DWORD,:DWORD,:QWORD,:DWORD
.DATA
hInst DQ ?
szTitle DB "Test StringCchCat",0
str1 DB "I learn ",40h DUP (0)
str2 DB "assembly language.",0
.CODE
StringCchCatA PROC pszDest:QWORD,cchDest:DWORD,pszSrc:QWORD
LOCAL cchDestLength:DWORD
invoke StringValidateDestAndLengthA,pszDest,cchDest,ADDR cchDestLength,STRSAFE_MAX_CCH
cmp eax,0
jl exit
sub r10,r10
mov r10d,cchDestLength
mov rcx,pszDest
add rcx,r10
mov edx,cchDest
sub edx,cchDestLength
invoke StringCopyWorkerA,rcx,edx,0,pszSrc,STRSAFE_MAX_LENGTH
exit: ret
StringCchCatA ENDP
main PROC
invoke StringCchCatA,ADDR str1,SIZEOF str1,ADDR str2
invoke MessageBox,0,ADDR str1,ADDR szTitle,MB_OK
call ExitProcess
main ENDP
END
Please give me some advice for improvement, thank you for your help.
The same but shorter... :smiley:
include \masm64\include64\masm64rt.inc
.data
szTitle DB "Test StringCchCat",0
str1 DB "I learn ",40h DUP (0)
str2 DB "assembly language.",0
.code
main proc
lea r8,str1
lea r9,str2
@@:
cmp byte ptr[r8],0
lea r8,[r8+1]
jne @b
@@:
mov al,byte ptr[r9]
add r9,1
mov byte ptr[r8-1],al
add r8,1
test al,al
jne @b
invoke MessageBox,0,addr str1,addr szTitle,MB_OK
call ExitProcess
main endp
end
Hi, ognil:
The reason I called StringCchCatA was to avoid buffer overflow security issues, and since strsafe.lib wasn't available, I raised this question. Thank you for your concise and elegant code.
Quote from: wanker742126 on October 31, 2024, 09:12:01 AMPlease give me some advice for improvement...
* Keep it simple :biggrin: . Even the legacy API's will work fine for such a simple example.
A large buffer and a simple test of the concatenated string lengths against the buffer size will prevent buffer overflow.
Keep in mind that the buffer needs to be at least one byte (assuming ascii strings) longer than the length of the concatenated strings for proper zero termination of the buffer. I should have wrote that into this code, my bad. :tongue:
include \masm64\include64\masm64rt.inc
.data
szTitle db "Test lstrcat", 0
buffer db 256 dup (0)
str1 db "I learn ", 0
str2 db "assembly language.", 0
slen dd 0
.code
main proc
invoke lstrlen, addr str1 ;; get length of str1
mov slen, eax
invoke lstrlen, addr str2 ;; add length of str2
add eax, slen
cmp eax, sizeof buffer ;; compare length with buffer size
jg buffererror ;; if length of strings greater than buffer size, show error message
invoke lstrcpy, addr buffer, addr str1
invoke lstrcat, addr buffer, addr str2
invoke MessageBox, 0, addr buffer, addr szTitle, MB_OK
jmp xit
buffererror:
fn MessageBox, 0, "buffer overflow", addr szTitle, 0
xit:
invoke ExitProcess, 0
main endp
end
Just use the included batch file to build this example. :smiley:
Edit: I just noticed that I used "eax" here, which should be fine in this context... the buffer size is well below the limits of eax. :mrgreen: Others may find that objectionable. :tongue:
zedd151:
Indeed, I got a bit fixated on using StringCchCatA. Your code certainly prevents buffer overflow, and it's simple and clear. However, during my search, I also learned more about the nature of strsafe.lib and how to call StringCchCatA and other StringCch* functions.
It's all good. More knowledge is always a good thing. But I like the more simple solutions myself.
Happy coding. :thumbsup:
Who doesn't love simple solutions? It's just that multiple books mention, and even MSDN points out, that functions like lstrlen, lstrcpy, wcscat, etc., have security concerns, recommending the use of StringCch* functions instead. This sparked my curiosity. In fact, I've traced StringCchCatA, and it essentially just checks that the buffer size is greater than the length of the two strings being concatenated.
I just used lstrlen lstrcpy and lstrcat for demonstration of a simple approach to the problem, using widely available API's.
Normally I would "roll my own" algorithms to do the same functionality, and ognil also showed some of that type of code (replacing functionality of lstrcat). I would put that code into its own procedure though, for reusability in other programs. :smiley:
I learned from this experience that "blindly trusting books can be worse than having no books at all." :biggrin:
Have to know context, like using untrusted data.
MSDN don't tell all details of functions.
Quote from: zedd151 on November 01, 2024, 02:21:35 AMI just used lstrlen lstrcpy and lstrcat for demonstration of a simple approach to the problem, using widely available API's.
Normally I would "roll my own" algorithms to do the same functionality ... I would put that code into its own procedure though, for reusability in other programs. :smiley:
Here is an example of "self rolled" functions to get string length, concatenate two strings, copy string to a buffer:
stringcat proc dst:qword, src:qword ;; rcx = dst (destination), first argument ;; rcx = src (source), second argument
dec rcx
findend:
inc rcx
cmp byte ptr [rcx], 0
jnz findend
dec rdx
dec rcx
copyit:
inc rdx
inc rcx
mov al, [rdx]
mov [rcx], al
cmp byte ptr [rdx], 0
jnz copyit
mov byte ptr [rcx], 0 ;; ensure zero termination.
ret
stringcat endp
stringcpy proc dst:qword, src:qword ;; rcx = dst (destination), first argument ;; rdx = src (source), second argument
dec rdx
dec rcx
copyit:
inc rdx
inc rcx
mov al, [rdx]
mov [rcx], al
cmp byte ptr [rdx], 0
jnz copyit
mov byte ptr [rcx], 0 ;; ensure zero termination.
ret
stringcpy endp
stringlen proc src:qword ;; rcx = src (source), first and only argument
dec rcx
xor rax, rax
dec rax
countbyte:
inc rax
inc rcx
cmp byte ptr [rcx], 0
jnz countbyte
ret
stringlen endp
Full source for attached example:
include \masm64\include64\masm64rt.inc
.const
str1 db "Hello", 0
strspace db " ", 0
str2 db "World!", 0Dh, 0Ah, 0
str3 db "64 bit assembly example", 0
strerror db "Buffer overflow", 0
.data
str1len dq 0
spacelen dq 0
str2len dq 0
buffer db 128 dup (0)
.code
start proc
invoke stringlen, addr str1
mov str1len, rax ;; length of str1
invoke stringlen, addr strspace
mov spacelen, rax ;; length of strspace
invoke stringlen, addr str2
mov str2len, rax ;; length of str2
invoke stringlen, addr str3 ;; length of str3 (in rax after call, not in a variable)
add rax, str1len
add rax, spacelen
add rax, str2len ;; add all the string lengths
cmp rax, sizeof buffer ;; compare to buffer size
jge buffererr ;; jump if greater or equal to display error if failed
invoke stringcpy, addr buffer, addr str1 ;; else display message box with all strings concatenated
invoke stringcat, addr buffer, addr strspace
invoke stringcat, addr buffer, addr str2
invoke stringcat, addr buffer, addr str3
fn MessageBox, 0, addr buffer, 0, 0
jmp xit ;; jump over error message if succesful
buffererr:
invoke MessageBox, 0, addr strerror, 0, 0
xit:
invoke ExitProcess, 0
start endp
stringcat proc dst:qword, src:qword ;; rcx = dst (destination), first argument ;; rcx = src (source), second argument
dec rcx
findend:
inc rcx
cmp byte ptr [rcx], 0
jnz findend
dec rdx
dec rcx
copyit:
inc rdx
inc rcx
mov al, [rdx]
mov [rcx], al
cmp byte ptr [rdx], 0
jnz copyit
mov byte ptr [rcx], 0 ;; ensure zero termination.
ret
stringcat endp
stringcpy proc dst:qword, src:qword ;; rcx = dst (destination), first argument ;; rdx = src (source), second argument
dec rdx
dec rcx
copyit:
inc rdx
inc rcx
mov al, [rdx]
mov [rcx], al
cmp byte ptr [rdx], 0
jnz copyit
mov byte ptr [rcx], 0 ;; ensure zero termination.
ret
stringcpy endp
stringlen proc src:qword ;; rcx = src (source), first and only argument
dec rcx
xor rax, rax
dec rax
countbyte:
inc rax
inc rcx
cmp byte ptr [rcx], 0
jnz countbyte
ret
stringlen endp
endedit: added code to ensure zero termination in the 'stringcpy' and 'stringcat ' functions
Slightly optimised...just as an exercise :biggrin:
stringcat proc dst:qword, src:qword ;; rcx = dst (destination), first argument ;; rcx = src (source), second argument
@0: inc rcx
cmp byte ptr [rcx-1],0
jnz @0
@1: mov al,[rdx]
mov [rcx-1],al
inc rdx
inc rcx
test al,al
jnz @1
ret
stringcat endp
stringcpy proc dst:qword, src:qword ;; rcx = dst (destination), first argument ;; rdx = src (source), second argument
@0: mov al,[rdx]
mov [rcx],al
inc rdx
inc rcx
test al,al
jnz @0
ret
stringcpy endp
stringlen proc src:qword ;; rcx = src (source), first and only argument
or rax,-1
@@: inc rax
cmp byte ptr [rcx+rax],0
jnz @b
@@: ret
stringlen endp
Since the procs don't call any other proc you could turn off frame generation, but I'm not sure how to disable then enable it with the MASM64 SDK :sad:
Hi sinsi, yes the algos I presented could be optimized, but that would not be Campus material. Better suited for the Laboratory imo. :tongue:
Also you should ensure zero termination in both stringcat and stringcpy (by placing a zero byte when finished there) since the buffer may already have data in it from a possible previous use of the buffer. correction, my mistake. :tongue:
:biggrin:
Quote from: zedd151 on November 01, 2024, 04:46:16 AMHi sinsi, yes the algos I presented could be optimized, but that would not be Campus material. Better suited for the Laboratory. :tongue:
The Campus is for learning, maybe someone can learn from this?
Quote from: zedd151 on November 01, 2024, 04:46:16 AMAlso you should ensure zero termination in both stringcat and stringcpy (by placing a zero byte when finished there) since the buffer may already have data in it from a possible previous use of the buffer. :icon_idea:
All characters are copied, even the terminating NULL, then end-of-string is tested for.
Oh, ok. I only did a quick perusal at the code. Apologies. :cool:
Quote from: sinsi on November 01, 2024, 04:50:02 AMAll characters are copied, even the terminating NULL, then end-of-string is tested for.
Clever indeed. I just tested your algos in the program using a "full" buffer... :biggrin: Works 100% as it should. :thumbsup:
Yes, someone could learn from your example. :smiley: My critique was only a suggestion.
One more.. :smiley:
include \masm64\include64\masm64rt.inc
extern malloc:proc
extern free:proc
.data
hMemo DQ 0
szTitle DB "Test StringCchCat",0
str1 DB "I learn ",0
nLen1 equ $-str1-1
str2 DB "assembly language.",0
nLen2 equ $-str2-1
.code
main proc
mov eax,nLen1
mov ecx,nLen2
lea rcx,[rcx+rax+32]
call malloc
mov rcx,rax
jrcxz @ErrMemory
mov r8d,nLen1
lea rdx,str1
mov hMemo, rax
lea r9,[rcx+r8]
call memcpyA
mov rcx, r9
mov r8d,nLen2
lea rdx,str2
call memcpyA
invoke MessageBox,0,hMemo,addr szTitle,MB_OK
;mov rcx,hMemo
;call free
@ErrMemory:
call ExitProcess
main endp
;*******************************************************************;
memcpyA proc
push rsi
push rdi
cld
mov rdi,rcx
mov rcx,r8
mov rsi,rdx
shr rcx, 3
rep movsq
mov rcx,r8
and rcx, 7
rep movsb
pop rdi
pop rsi
ret
memcpyA endp
end
Quote from: zedd151 on November 01, 2024, 04:51:19 AMMy critique was only a suggestion.
Hey, I didn't even consider it a critique, just a statement :biggrin:
In my not-so-humble opinion, nearly all of the string functions ought to be written by the programmer as learning exercises, rather than relying on canned library functions. At least that's what I've done (in 32-bit code):
- strlen()
- strcpy()
- strcat
- strcmp()
This covers probably 95% of what actually gets used, and these are not at all difficult to write.
If you need fast routines, you can either optimize these yourself or search this site for the mo-fasta code that people have written. But usually string manipulation is not something where speed really matters.
Returning to my original question, I'd like to ask about the code for StringCchCatA in strsafe.h:
STRSAFEAPI
StringCchCatA(
_Inout_updates_(cchDest) _Always_(_Post_z_) STRSAFE_LPSTR pszDest,
_In_ size_t cchDest,
_In_ STRSAFE_LPCSTR pszSrc)
{
HRESULT hr;
size_t cchDestLength;
hr = StringValidateDestAndLengthA(pszDest,
cchDest,
&cchDestLength,
STRSAFE_MAX_CCH);
if (SUCCEEDED(hr))
{
hr = StringCopyWorkerA(pszDest + cchDestLength,
cchDest - cchDestLength,
NULL,
pszSrc,
STRSAFE_MAX_LENGTH);
}
return hr;
}
If I were to rewrite this in assembly language, would it look something like this?
StringCchCatA PROC pszDest:QWORD,cchDest:DWORD,pszSrc:QWORD
LOCAL cchDestLength:DWORD
invoke StringValidateDestAndLengthA,pszDest,cchDest,ADDR cchDestLength,STRSAFE_MAX_CCH
cmp eax,0
jl exit
sub r10,r10
mov r10d,cchDestLength
mov rcx,pszDest
add rcx,r10
mov edx,cchDest
sub edx,cchDestLength
invoke StringCopyWorkerA,rcx,edx,0,pszSrc,STRSAFE_MAX_LENGTH
exit: ret
StringCchCatA ENDP
If there are any mistakes, please let me know.
invoke StringValidateDestAndLengthA,pszDest,cchDest,ADDR cchDestLength,STRSAFE_MAX_CCH
cmp eax,0
jl exit
Pretty sure the return value from a Windows function will never be negative. All unsigned values.
Quote from: NoCforMe on November 01, 2024, 07:06:43 PMPretty sure the return value from a Windows function will never be negative. All unsigned values.
The function (like a lot of others) returns a HRESULT.
Quote from: WikipediaHRESULT is defined in a system header file as a 32-bit, signed integer
Usually the high bit set signifies an error.
QuoteBit 31: S - Severity - indicates success (0) or failure (1)
#if !defined(_HRESULT_DEFINED) && !defined(__midl)
#define _HRESULT_DEFINED
typedef long HRESULT;
#endif /* _HRESULT_DEFINED */
FORCEINLINE HRESULT HRESULT_FROM_WIN32(unsigned long x) {
return (HRESULT)(x) <= 0 ? (HRESULT)(x) : (HRESULT)(((x) & 0x0000FFFF) | (FACILITY_WIN32 << 16) | 0x80000000);
}
in strsafe.h#ifndef _HRESULT_DEFINED
#define _HRESULT_DEFINED
typedef long HRESULT;
#endif /* _HRESULT_DEFINED */
typedef unsigned long DWORD;
#define SUCCEEDED(hr) (((HRESULT)(hr)) >= 0)
#define FAILED(hr) (((HRESULT)(hr)) < 0)
#define S_OK ((HRESULT)0L)
Quote from: sinsi on November 01, 2024, 08:12:27 PMUsually the high bit set signifies an error.
QuoteBit 31: S - Severity - indicates success (0) or failure (1)
Ah so. Thanks. I stand (sit) corrected.