fix HalRequestIpi prototype, comment out IO access functions for amd64, add hal_amd64.def and a tiny amd64/hal_generic.c
svn path=/branches/ros-amd64-bringup/; revision=34743
now setupldr should compile, and start it's work. It boots into long mode, reads the memory layout from bios and finally crashes, because the page table is limited to a single page of 2MB atm
svn path=/branches/ros-amd64-bringup/; revision=34727
- add amd64 to rbuild files
- add include/amd64 and arch/amd64 and copy some files from i386, maybe we can later share some of them between those architectures
- convert fathelp.asm to fathelp.S so we can link it. Content stays the same as for i386
svn path=/branches/ros-amd64-bringup/; revision=34725
- fix prototypes of _findfirst, _findnext, _findclose, _findfirsti64, _findnexti64 _wfindfirst, _wfindnext, _wfindfirst64, _wfindnext64, strndup,
- fix a number of pointer to int casts
svn path=/branches/ros-amd64-bringup/; revision=34717
- amd64/add debug_asm.S (FIXME)
- cast AtomName to ULONG_PTR instead of ULONG
- RtlQueryProcessdebugInformation(): cast teb->Cid.UniqueProcess to ULONG_PTR for assignment to Pid. (should ProcessId parameter be ULONG_PTR, too?)
- vs(w)nprintf: cast argument to ULONG_PTR instead of unsigned long for a %p
- comment out some inlined Interlocked functions that shouldn't be there anyway
Now rtl can be compiled
svn path=/branches/ros-amd64-bringup/; revision=34716
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
Timo Kreuzer