Fix a copy-paste bug. Adjust the number when subtracting in Fast486FpuAdd. Don't overflow
the mantissa in Fast486FpuToSingle/Fast486FpuToDouble without correcting the exponent.
svn path=/trunk/; revision=67838
INI files for setting parameters? Lets get to the past Win 3.11 standards and make a configure dialog for that which reads and writes the stuff to the registry.
svn path=/trunk/; revision=67833
Followup to r67830: When no one handles a message, properly return that it was not handled.
This way all messages are handled correctly and not just NCCREATE.
Also took the chance to short-cut NCDESTROY, since the icon handlers have no need to receive this message.
CORE-9592 #resolve
svn path=/trunk/; revision=67831
do not handle WM_NCCREATE in ProcessWindowMessage
otherwise it get passed to ProcessIconMessage which will flag it as handled in case g_NumIcons is 0
which then will result in ATL not calling DefWndProc anymore
CORE-9592
svn path=/trunk/; revision=67830
Fix Fast486FpuArithmeticOperation. It doesn't really matter for the operation
itself which operand is the source/destination, because the FPU actually
always performs the operation on ST0 and something else. So, FDIV/FDIVR were
never really reversed here, it's just that FDIV always divides ST0 by something
and FDIVR always divides something by ST0.
svn path=/trunk/; revision=67828
Fix UnsignedDivMod128 (again).
Fix Fast486FpuAdd to handle numbers whose difference of exponents is greater than
the number of bits in the mantissa.
svn path=/trunk/; revision=67827
The maximum length of hardware profiles names is 79 characters. Use a matching string length and set the length of the edit control accordingly.
svn path=/trunk/; revision=67825
Implement support for FastIO for:
- FastIoQueryBasicInfo
- FastIoQueryStandardInfo
Now, with this commit and the two previous, ReactOS won't attempt to issue an IRP for these query, but will directly go with the FastIO path.
The performance improvement is really visible in 1st stage (at least, here with VBox).
svn path=/trunk/; revision=67824
Fix several division related problems:
- In UnsignedDivMod128, fix the leading zero calculation for 128-bit numbers.
- In Fast486FpuDivide, there's no need to increase the exponent by 64 (adding zeros
at the end of a number after the decimal point changes nothing).
- FDIV/FDIVR were reversed
svn path=/trunk/; revision=67820
- Zero is not a denormalized number.
- In Fast486FpuMultiply, we must account for the fact that the resulting mantissa
also has the "decimal point" at the second position.
svn path=/trunk/; revision=67819
Implement MiGetFileObjectForSectionAddress and use it in MmGetFileNameForAddress and NtAreMappedFilesTheSame. Don't call MmLocateMemoryAreaByAddress from these functions anymore.
svn path=/trunk/; revision=67810
Fix a fixme in VfatGetUserBuffer():
Only request high priority page when in the paging path. Otherwise, request normal priority
svn path=/trunk/; revision=67808
Don't check if a AMR3 owned memory area can be inserted, since we already know it's ok. Delete the related memory area code.
svn path=/trunk/; revision=67798
Add a tiny hack to MiFindEmptyAddressRangeInTree and MiFindEmptyAddressRangeDownTree to support VADs in the kernel VA range. Make MmFindGap use those functions to look for free space.
svn path=/trunk/; revision=67797
Get rid of MiRosTakeOverSharedUserPage. We don't need it anymore, since the user page is manually handled in the page fault handler and since it's outside the VAD region, we don't need to block that range. Now there should be no memory areas left at all in MmDeleteProcessAddressSpace.
svn path=/trunk/; revision=67796
Modify MmLocateMemoryAreaByAddress as well to use the VAD table. Since the page fault handler uses it to find ARM3-Fault pages and the shared user page does have a memory area, but not a VAD, add a check for the shared user page in the old fault handler.
svn path=/trunk/; revision=67795
Implement MiRosCleanupMemoryArea to cleanup memory areas from MmCleanProcessAddressSpace, since later when we remove the old-style memory area links, we will not be able to retrieve those.
svn path=/trunk/; revision=67794
Use the VAD tree to search for MEMORY_AREAS, except when inserting an ARM3 based MA. In this case we still need to use the old tables, since the related VAD is already inserted into the VAD tree.
svn path=/trunk/; revision=67793
- Allocate Memory area before trying to insert it in different pathes of MmCreateMemoryArea. This change is a preparation for upcoming changes.
- Cleanup MmInsertMemoryArea from useless stuff
svn path=/trunk/; revision=67791
Use 1 as base address parameter to MmCreateMemoryArea, when 0 is the actual base and remove FixedAddress parameter in MmCreateMemoryArea
svn path=/trunk/; revision=67790