Add fix ups to PolyPatBlt and freetype.
TextOut supports 580 characters w/o Dx and Dx at a max of 193 characters
with Dx*1, both if offset is 0.
Noticed a lot of over drawing with start menu from ComCtl32 SB_SETTEXT
going through User32 DrawText/Worker ExtTextOutW. Explain why it might
be slowing down.
If issues arise, commenting out lines in win32ss/include/gdi32p.h can
help.
Example:
else if (Cmd == GdiBCTextOut) cjSize = 0;//sizeof(GDIBSTEXTOUT); <----
this one most of all.
else if (Cmd == GdiBCExtTextOut) cjSize = 0;//sizeof(GDIBSEXTTEXTOUT);
Test results:
https://reactos.org/testman/compare.php?ids=66260,66262
Separate TextOut for internal use.
Use flTextAlign internally.
Not sure why GetDeviceCap was used for determining rendering. SVN commit
logs are unavailable. Include code from wine that might make more sense.
MSVC was previously given a "result" variable to copy the fscale result from st(0). This led to another "fld" FPU stack push at the very end without popping the source value from the FPU stack.
Moreover, this copy isn't even needed: A simple "fstp st(1)" at the end pops an element from the FPU stack while effectively storing the result in st(0), the register used for returning a double value.
This problem didn't affect GCC, as it is only given the "fscale" instruction and does all necessary stack operations itself.
However, looking into the CRT sources, I found many other i386 implementations with inline assembly suffering from the same problem.
Fortunately, they have been replaced by pure assembly implementations a while ago, so it's time to finally remove them.
ldexp would have also been a candidate for a pure assembly implementation, but the required check for NaN and setting errno (verified on Win2003) already outweighs the benefits.
And we cannot just do a NaN check with FUCOMI as this is an i686/pentiumpro instruction while we're still targeting i586/pentium.
I'm also using this opportunity to clean up the ldexp.c header and only put in the remaining contributors as returned by "git blame".
Thanks to NightWolve1975 for reporting the problem! (https://twitter.com/nightwolve1975/status/1099042477531643912)
This stub is responsible for providing the UUID seed to the kernel.
For now, it generates a purely random seed - MAC address support
is to be added.
Because it's purely random seed and local the machine (not tied
to the MAC address) it's made so that ExUuidCreate keeps returning
RPC_NT_UUID_LOCAL_ONLY. It won't fix failing test for now.
Nota: this service shouldn't exist as it. It should be implemented
though rpcss DLL for both rpcss service (network service) and
dcomlaunch service (local system service).
Because rpcss is EXE based and wine-synced for now, I prefered
stubbing a new service. This will have to be changed at some point.
IDD_BROWSE_FOR_FOLDER displays text controlled by the calling applications in
IDC_BROWSE_FOR_FOLDER_TITLE. Its old height could lead to text truncation
for existing 3rd party apps.
The new height value for IDC_BROWSE_FOR_FOLDER_TITLE
was inspired by IDC with the same from dialog IDD_BROWSE_FOR_FOLDER_NEW.
I could change all languages to the same height,
as dimensions of the dialog and surrounding controls were same.
