- Plug in the dispatch routines. These are just pass through methods for now to get the filter up and running.
- Implement the FastIo handlers. The majority of these call the FastIo routines of the attached device object.
- Make sure we detach from devices that are being deleted in FastIoDetachDevice.
- Move the FastIoDetachDevice routine to a deferred call as it's too expensive to tie up a FastIo request.
svn path=/trunk/; revision=70488
Fix the fix from r70482: Our DIBs are actually 32 bit aligned, so pass even uncompressed bits to GreCreateBitmapEx instead of copying them later with wrong alignment.
svn path=/trunk/; revision=70486
NtGdiCreateDIBitmapInternal: clear CBM_INIT flag, if no bits are given.
IntSetDIBits: Always calculate the bitmap size for uncompressed bitmaps, do not pass uncompressed bits to GreCreateBitmapEx, since they don't have the required alignment (the width in bytes for DIB is 16 bit aligned, bitmaps 32).
Remove a broken ASSERT.
svn path=/trunk/; revision=70482
Implement LsarStorePrivateData and LsarRetrievePrivateData.
[ADVAPI32]
Implement LsaRetrievePrivateData and LsaStorePrivateData.
Encryption of secrets (aka private data) is NOT implemented yet!
svn path=/trunk/; revision=70479
Factorize the code that creates ReactOS freeldr.ini entries, and use it to create a freeldr.ini at a clean ReactOS installation, and when it is installed in the same partition as Win9x/DOS.
CORE-4870 #comment Should be fixed with revision 70467, please retest.
svn path=/trunk/; revision=70467
Properly check the bitmap size in IntSetDIBits, taking into account that it might be set to 0, then we have to calculate it ourselves. Fixes a crash when invalid data is passed to NtGdiCreateDIBitmapInternal.
[GDI32]
Convert COREINFOHEADER to BITMAPINFOHEADER before passing it to NtGdiCreateDIBitmapInternal, which doesn't support it.
CORE-10583 #resolve
svn path=/trunk/; revision=70464
Export NtUserGetClassInfoEx (as it's called in 2k3) both as NtUserGetClassInfo (as it's called on XP) and NtUserGetClassInfo. They have the same prototype.
svn path=/trunk/; revision=70463
- "Fix" an export name: NtUserGetClassInfoEx on 2k3 is the same as NtUserGetClassInfo on XP (note that we currently use the default, aka ros specific, win32kdll on the WHS testbot, but it's mostly identical.
[WIN32KNT_APITEST]
- Fix a typo
- add missing tests to testlist.c
svn path=/trunk/; revision=70462
- Convert win32k native api test to actual wine style api-tests
- Hack around a bit with the win32k dlls, some renaming, etc.
- Delete old apitest stuff
svn path=/trunk/; revision=70458
Don't use DATA and PRIVATE together. DATA means no stub function is generated in the import lib, PRIVATE means nothing is generated in the export lib.
svn path=/trunk/; revision=70454
Now, the fix: the FAT disk checker expected that the free cluster count member of the FAT32 FSInfo sector be really initialized (not to 0xFFFFFFFF), and it expected the presence of the backup of the FSInfo sector as well as the free sector following the FSInfo sector.
svn path=/trunk/; revision=70449
- DPRINT messages printed via VfatPrint by the check-disk procedure.
- Addendum to r70434 and r70435 : The return value of fs_close is equal to the number of corrections made on the disk (0 corrections --> success; 1+ --> something was corrected).
That way, the old code "return fs_close(FixErrors) ? STATUS_SUCCESS : STATUS_UNSUCCESSFUL;" that we had since eons (which always happened to return STATUS_SUCCESS) was actually
indicating to us that our FAT32-formatted volumes were corrupted.
If you test this revision, you should see something happening if you try to install ReactOS now (something that should have happened since ages actually).
svn path=/trunk/; revision=70447
- Formatting + RtlZero/FillMemory modifications as addendum to r70445.
- Do not hardcode FSInfo signature values, use instead the same set of macros fastfat_new introduces.
svn path=/trunk/; revision=70446
Fix handling of NULL buffer in streamout. Fixes a few msvcrt_crt_apitests, while it breaks a few for crtdll. crtdll is broken anyway and obsolete, nothing uses it, so it doesn't really matter.
CORE-9105 #resolve
svn path=/trunk/; revision=70443
It seems suspicious to directly return the value of fs_close as the NTSTATUS code of the check-disk operation (for FAT32 volumes it happens to return 1 whereas for FAT16 volumes it returns 0).
The documentation of this function says that it "returns a non-zero integer if the file system has been changed since the last fs_open, zero otherwise."
Maybe somebody has a more precise idea on that subject? In the meantime I also add some DPRINTs to attempt to diagnose the conditions where this problem occurs.
svn path=/trunk/; revision=70434
- Gather common code in one file instead of duplicating it everywhere.
- Implement full format for FAT12 and FAT16 (using the same function Fat1216WipeSectors), based on similar code for FAT32 implemented by Eric Kohl in revision 63693.
svn path=/trunk/; revision=70433
- fat.asm: remove trailing whitespace.
- fat32.asm: backport the fixes from fat32.S introduced a long time ago.
- fat32.S/faty.S: use .space 12, 0 instead of the long .byte array (generates the same code, but is better readable).
- isoboot/btrt: whitespace fix only.
svn path=/trunk/; revision=70432
