that bring us closer to the Windows 2000 DMA model.
adapter.c: significantly re-worked and heavily commented
hal.h: more additions to ADAPTER_OBJECT; more pending
dma.c: added initialization of ADAPTER_OBJECT
ndis/io.c: minor DMA changes and addition of fixmes
svn path=/trunk/; revision=6411
- Fixed WindowClass->hbrBackground == (COLOR_* + 1) bug I introduced, but now it's working the right way.
- Copied system coloe code from user32 to win32k, where it was messy!
svn path=/trunk/; revision=6401
- Update registry with new 3com infor and set cards to disable by default
- removed unnecessary crap from miniport.h
- switch to using MINIPORT_BLOCK whenever possible for internal NDIS stuff
- implemented NdisGetBufferPhysicalArraySize
- fixed three similar bugs with overwriting memory in the config api
- implemented NdisMQueryAssignedResources
- fixed NdisMAllocateMapRegisters
- implemented NdisMStartPhysicalBufferMapping
- implemented NdisMCompletePhysicalBufferMapping
- implemented NdisMMapIoSpace
- implemented NdisMUnmapIoSpace
- fixed HalAllocateAdapterChannel and IoAllocateAdapterChannel to
act more like windows
- fixed up a couple of enums
- other misc. stuff
svn path=/trunk/; revision=6382
- Very basic implementaion of NtUserPaintDesktop.
- Fixed bug in default window WM_ERASEBKGND.
- Fixed bug in default window WM_PAINT.
- Made BeginDeferWindowPos, DeferWindowPos, EndDeferWindowPos pseudo-working by returning values that make sense and calling SetWindowPos.
svn path=/trunk/; revision=6379
Nothing should change with the resulting binaries (although various #pragma pack directives may have an effect )^:
Clean build tested without problem. Hopefully haven't broken anything with the runtime, ROS still boots ok for me under BOCHS.
Lots of laborious work all to be chucked out once we can finally switch over to the mingw headers full time.
Sorry if this causes anybody�s uncommitted work to be in conflict.
Heaps more coming to an directory near you soon (if nobody objects of course)
I noticed somewhere something like an 'include next' directive, however I can't find it now. In order to save me the research can anybody enlighten me as to its purpose. What I am hoping for is that it tells the pre-proc to go to the next header of the same name in the 'includes' search path. Such a directive would certainly be useful right now!
Regarding the mention on ros-kernel about wine-msvcrt v's ros-msvcrt I was hoping that the mingwacr project would addrs this however it seems to have lost all its steam. Anybody got an update concerning the project?
Somewhat off topic: finally the rains have come -> http://mirror.bom.gov.au/products/IDR032.loop.shtml#image
svn path=/trunk/; revision=6368