When using software gdi (/gdi:sw) the rdp update PDU callback
gdi_palette_update() is used which writes the new colors to
the rdpContext's gdi->palette buffer.
The X11 functions however access xfc->palette which gets only
updated by xf_gdi_palette_update() which is the callback if
/gdi:hw is used.
This commit changes xfc->palette to a pointer which points to
xfc's private buffer with /gdi:hw or to the gdi->palette if
software gdi is used.
If no entry for the <host> <port> combination
was found in the v2 file and there is a legacy file
check if a matching <host> entry can be found.
In case there is a matching entry and the <fingerprint>
also matches, create a new entry in the v2 file using the
current port.
Note: This commit does NOT really fix PathAllocCombine!
- print a warning message that the function is buggy and added a code
comment describing the issues
- fix misuse of the S_FALSE HRESULT in error conditions
- prevent some segfaults
- check result of HeapAlloc
Fortunately PathAllocCombine is unused in FreeRDP
Fix multiple inplementation errors including the incorrect usage of S_FALSE.
Make this function behave like the Windows 8 implementation and
the according MSDN specification.
- return S_OK if the extension was NOT found
- if no extension was found, ppszExt must point to the string's terminating null
- return E_INVALIDARG if pszPath is not null-terminated within the cchPath range
- return E_INVALIDARG if pszPath is NULL
- return E_INVALIDARG if ppszExt is NULL
- return E_INVALIDARG if cchPath is Zero
- return E_NOTIMPL instead of S_OK in PathPathCchFindExtensionW()
Also extended/fixed the TestPathCchFindExtension ctest
Fix incorrect usage of S_FALSE which was used to indicate errors
although it is a HRESULT success code.
Make this function behave like the Windows 8 implementation and
the according MSDN specification.
- return E_INVALIDARG instead of S_FALSE if pszPath is NULL
- return E_INVALIDARG instead of S_FALSE if pszMore is NULL
- return E_INVALIDARG if cchPath is zero
- return E_INVALIDARG if cchPath is greater than PATHCCH_MAX_CCH
- return HRESULT_FROM_WIN32(ERROR_FILENAME_EXCED_RANGE) if the combined
path size exceeds cchPath (this is the same HRESULT which the Windows
implementation returns in this case and which is referred to as
PATHCCH_E_FILENAME_TOO_LONG on msdn)
Also extended/fixed the TestPathCchAppend ctest
And again S_FALSE was incorrectly used to indicate an error.
Fix this and be more compatible to the Windows 8 implementation of
this function:
- return E_INVALIDARG instead of S_FALSE if pszPath is NULL
- return E_INVALIDARG instead of S_FALSE if cchPath < 4
- return E_INVALIDARG if cchPath > PATHCCH_MAX_CCH
- allow stripping of "\\?\c:" and don't require "\\?\c:\"
- verify that the character at the drive letter position is
actually an alphabetic character
- since the passed pszPath must not necessarily be null terminated
and we always have enough space after the memmove we can always
ensure the null termination of the stripped result
Also extended/fixed the TestPathCchStripPrefixctest
The HRESULT S_FALSE does not indicate an error:
- return E_INVALIDARG instead of S_FALSE
- return HRESULT_FROM_WIN32(ERROR_INSUFFICIENT_BUFFER) instead of S_FALSE
Also extended/fixed the corresponding ctest
The HRESULT S_FALSE does not indicate an error:
- return E_INVALIDARG instead of S_FALSE
- return HRESULT_FROM_WIN32(ERROR_INSUFFICIENT_BUFFER) instead of S_FALSE
Also extended/fixed the corresponding ctest
The HRESULT S_FALSE does not indicate an error:
- return E_INVALIDARG instead of S_FALSE
- return HRESULT_FROM_WIN32(ERROR_INSUFFICIENT_BUFFER) instead of S_FALSE
Also extended/fixed the corresponding ctest
