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.
- Implement the save/load handler for this feature
- Check the "Use Click Sound" item state accordingly depending if it's enabled or disabled
- Use PlaySoundW() to play the wave sound file from resource
- Add the WAV sound click file. The work is made thanks to Midori Mizuno
We previously only gave the device a hard-coded amount of time to respond,
which could lead to interpreting the contents of uninitialized memory as
a response. This would lead to an unreasonably large number of audio function
groups being detected.
A KSEMAPHORE mirrors what Haiku uses here, though it may not be the optimal
synchronization primitive for this case under Windows.
This protects against crashing in case of faulty/malicious hardware,
but also works around a bug in HDA_SendVerbs that causes it to return
invalid data, thereby suggesting more groups than are actually present.
This will avoid 0-sized allocations, or -1-sized allocations.
So far, it's maxed by hard value stored in TCPIP.sys. I believe
this is not right and would deserve a true fix
* Add all wallpapers to the ISO and can look how enable the module in ReadMe.txt
* Remove blanks in name.
* Moving to folder with same wallpaper style.
* Adding and updating CMakeLists.txt.
* Update ReadMe.txt.
* 1 "warning: variable 'Status' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]"
* 2 "warning: comparison of unsigned expression < 0 is always false [-Wtautological-unsigned-zero-compare]"
* Use a consistent type for "i" and fix a comment
* Also update licence header.
CORE-14306
