Memory DC "supports drawing operations on a bitmap" according to MSDN, so why changing device's palette? I think it was not done for a reason, and if you can't test, don't touch before you have a test application.
- Reformat another part of 24104, and include warning messages too, to track palette failures.
- Put two mandatory debug prints to see when the code is being hit (one to memory managed DC case, and another one to the code commented out by Jim).
- Tested with abiword, FF 1.5 and 2.0, openoffice 2.0 installer, in 8, 24 and 32 bit color modes, no problem arised, and no debug messages flood happened.
svn path=/trunk/; revision=34695
- OpenConsoleW: Fourth parameter is actually share mode (passing a number from 0 to 2 will usually give ERROR_SHARING_VIOLATION on Windows)
- CreateFileW: Move CONIN$/CONOUT$ handling after dwCreationDisposition checks (it must be valid, even though it doesn't matter which it is); pass FILE_SHARE_READ|FILE_SHARE_WRITE to OpenConsoleW (dwShareMode is ignored).
- CloseConsoleHandle, CsrReleaseObject, CsrVerifyObject: Remove IsConsoleHandle checks - Windows ignores lower 2 bits of handle for closing and verifying.
- SetConsoleMode: Remove IsConsoleHandle check - it's redundant, since the same check is done in CsrGetObject.
- CsrIsConsoleHandle, CsrReleaseObjectByPointer: Clean up a bit.
- CsrFreeConsole: Remove the process from the console's list.
svn path=/trunk/; revision=34694
- Tested with Opera 9.51(still breaks when getting the page see bug 3465), FF, Seamonkey, Abiword, and the rest of our applications.
svn path=/trunk/; revision=34691
- CreateFileW: Pass CONIN$/CONOUT$ opens to OpenConsoleW.
- DuplicateConsoleHandle: Remove ProcessId from request structure, since console handles can only be duplicated in the calling process.
Don't check low bits of handle (Windows ignores them), but do check options and (if DUPLICATE_SAME_ACCESS is not specified) access mode.
- OpenConsoleW: Make wsName parameter const; allow any combination of GENERIC_READ and GENERIC_WRITE, don't require both.
- CreateConsoleScreenBuffer: Add parameter checks; return INVALID_HANDLE_VALUE (not FALSE) on failure.
- Remove remnants of unnecessary handle in Get/SetConsoleTitle.
- CsrDuplicateHandle: Implement DUPLICATE_CLOSE_SOURCE and DUPLICATE_SAME_ACCESS options.
svn path=/trunk/; revision=34685
- Fix a few issues in the cancel routine
- Don't wait on an event we haven't set
- Don't mark the IRP pending when in DispPrepareIrpForCancel
svn path=/trunk/; revision=34682
- zero initialize buffer
- check return value of SHGetSpecialFolderPathW
- zeroize buffer in ISF_MyDocuments_fnGetDisplayNameOf
svn path=/trunk/; revision=34678
- We now correctly mount the boot partition, scan for system drivers (none yet), and attempt loading ntdll.
- This actually works -- meaning the RAMdisk driver is working perfectly with vfatfs.sys and providing a virtual drive.
- We crash during mapping ntdll.dll due to some Mm issues we need to work out.
- Yes, we're almost at user-mode.
svn path=/trunk/; revision=34675
- Calculate number of cylinders too now.
- Save number of hidden sectors as well.
- Implement support for IOCTL_DISK_GET_PARTITION_INFO (RamdiskGetPartitionInfo).
- Implement support for IOCTL_DISK_GET_DRIVE_GEOMETRY (shared with IOCTL_CDROM_GET_GEOMETRY, IOCTL_STORAGE_GET_MEDIA_TYPES and IOCTL_DISK_GET_MEDIA_TYPES)
- DiskLength should be a LARGE_INTEGER.
- DiskOffset should be signed.
svn path=/trunk/; revision=34666
- Try to implement RamdiskMapPages for boot disks as it seems we're calling them now...
- The math works and the I/O mapping too, but I'm not sure we're reading correct data, so still left this unimplemented for now.
svn path=/trunk/; revision=34659
- Defined some proper constants (somewhat based on guesses, but should be mostly correct) for the DiskType.
- Now the code actually makes sense, instead of talking about CD-ROM File Systems and CD-ROMs everywhere (and Controllers and...floppies?!)
svn path=/trunk/; revision=34657
- In the future, please refer to other code which loops the current processors and gets their KPRCB before attempting a half-assed implementation. KiProcessorBlock should be used.
svn path=/trunk/; revision=34656
- Load vfatfs instead of CDFS.
- Implement code in the ramdisk driver to handle both ISO and FAT ramdisks. Don't know what the big deal with support ISO ramdisks was supposed to be, when our ramdisk is FAT, and dealing with FAT is a lot easier than CDFS (no TOC emulation and other rubbish that was added).
svn path=/trunk/; revision=34655
- Make CsrGetObject increment the ref count to prevent objects from being deleted while in use. Add CsrReleaseObjectByPointer calls where necessary.
svn path=/trunk/; revision=34652
- Optimize and simplify trap handling by using a common exit just like on x86's Kei386EoiHelper - KiExceptionExit. This way the code isn't duplicated 6 times.
- Do the same for system calls (KiServiceExit).
- Save the previous trap frame and restore it during each system call.
svn path=/trunk/; revision=34640
