- Ros-dev - ReactOS.org

by Aleksey Bragin

Hello, I'd like to hear opinions regarding the change in release policy. The proposition: Release happens on a strict time basis, like once per month. That means, at the end of the month we look for the best revision inside this month (probably which is closer to the end of the month), branch from it, apply all fixes (if any), and release. Disadvantage: a few coming releases' quality will be overall lower, there might be things like 0.3.25 (if release frequency is set too high, and this is not a disadvantage actually). Advantages: in the long run quality goes up, more developers due to higher release rate, more publicity, people will finally realize it's an alpha product, more bugs reported, no signs of a dead project (I doubt there are healthy projects doing 1 release per year :)). Any thoughts are appreciated. With the best regards, Aleksey Bragin.

18 years, 9 months

8
9
0 0

The first newsletter

by Dana Burkart

Okay, I'm in the middle of composing a test newsletter that will hopefully be accepted. I would like all the developers to respond to this with a short description of what they're currently working on so I can be as accurate as possible in that section of it (and I don't want to forget anyone). Thank you.

18 years, 9 months

3
2
0 0

Re: [ros-dev] [ros-diffs] [silverblade] 25108: Further stubbing of Kernel Streaming APIs (corrective path fix to follow...)

by Alex Ionescu

silverblade(a)svn.reactos.org wrote: > ============================================================================== > --- trunk/reactos/drivers/multimedia/drmk/drmk.def (added) > +++ trunk/reactos/drivers/multimedia/drmk/drmk.def Sun Dec 10 07:16:35 2006 > @@ -1,0 +1,12 @@ > +; > +; Exports definition file for drmk.sys > +; > + > +EXPORTS > +DrmAddContentHandlers@12 > +DrmCreateContentMixed@12 > +DrmDestroyContent@4 > +DrmForwardContentToDeviceObject@12 > +DrmForwardContentToFileObject@8 > +DrmForwardContentToInterface@12 > +DrmGetContentRights@8 > > Added: trunk/reactos/drivers/multimedia/drmk/drmk.rbuild We're so going to get slashdotted/hated for this :) -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 9 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [fireball] 25049: [AUDIT] Change name everywhere back to Ariadne because real person could not be contacted. Non-working email address removed. If this person doesn't contact me before finish of the audit, the copyright will be transferred to ReactOS Foundation.

by Thomas Weidenmueller

> If this person doesn't contact me before finish of the audit, the copyright will be transferred to ReactOS Foundation. There's no way such a transfer could be legally backed if the person who owns the copyright doesn't agree with it. - Thomas

18 years, 9 months

3
2
0 0

Re: [ros-dev] [ros-diffs] [mist] 25062: ReactOS Intel Mac compatibility commits, part 1/2, by Michael Steil. == A20 Gate and the Keyboard Controller == In order to turn on the A20 gate, the keyboard controller has to be emptied. This is done in freeldr by reading bytes until the keyboard controller signals it's empty. Intel Macs don't have PS/2 keyboard controller and the status register always reads back 0xFF, so the "there is data" bit will never be cleared. (The same problem has been in GRUB as well as i

by Aleksey Bragin

Thanks to these bugfixes, ReactOS now boots on Intel Macs (I tested it on Intel Core Duo MacMini), and in Parallels virtual machine. With the best regards, Aleksey Bragin. On Dec 4, 2006, at 6:00 PM, mist(a)svn.reactos.org wrote: > Author: mist > Date: Mon Dec 4 18:00:11 2006 > New Revision: 25062 > > URL: http://svn.reactos.org/svn/reactos?rev=25062&view=rev > Log: > ReactOS Intel Mac compatibility commits, part 1/2, by Michael Steil.

18 years, 9 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [gedmurphy] 25001: allow the Americans their incorrect spellings and add a correct UK resource file ; )

by Alex Ionescu

gedmurphy(a)svn.reactos.org wrote: > Author: gedmurphy > Date: Thu Nov 30 22:23:19 2006 > New Revision: 25001 > > URL: http://svn.reactos.org/svn/reactos?rev=25001&view=rev > Log: > allow the Americans their incorrect spellings and add a correct UK resource file ;) > We (Canadians) also know how to spell properly :) en-CA please! -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 9 months

9
11
0 0

Re: [ros-dev] [ros-diffs] [fireball] 25049: [AUDIT] Change name everywhere back to Ariadne because real person could not be contacted. Non-working email address removed. If this person doesn't contact me before finish of the audit, the copyright will

by Ged Murphy

On 12/4/06, Thomas Weidenmueller <w3seek(a)reactos.com> wrote: > > > If this person doesn't contact me before finish of the audit, the > copyright will be transferred to ReactOS Foundation. > > There's no way such a transfer could be legally backed if the person who > owns the copyright doesn't agree with it. I'm glad you said that, I was thinking the exact same thing but was gonna check before I posted anything. Ged.

18 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [arty] 25028: Partially unregress python 2.4 installer.

by Alex Ionescu

> Modified: branches/arty-stable/reactos/ntoskrnl/ps/process.c > URL: http://svn.reactos.org/svn/reactos/branches/arty-stable/reactos/ntoskrnl/ps… > ============================================================================== > --- branches/arty-stable/reactos/ntoskrnl/ps/process.c (original) > +++ branches/arty-stable/reactos/ntoskrnl/ps/process.c Sun Dec 3 13:42:35 2006 > @@ -560,6 +560,8 @@ > /* Create or Clone the Handle Table */ > ObpCreateHandleTable(Parent, Process); > > + memset(&Process->VadRoot, 0, sizeof(Process->VadRoot)); > + > /* Set Process's Directory Base */ > MmCopyMmInfo(Parent ? Parent : PsInitialSystemProcess, > Process, > > > Please use RtlZeroMemory in the kernel. Please keep in mind the compartmentalization of the kernel for large objects. Such a line should go somewhere like MmInitailizeXxx for the process. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 9 months

2
1
0 0

Greek keyboard layout

by stud1281＠freemail.gr

Hello guys. Sorry for bothering you again but can someone pls commit my Greek keyboard layout file? I want it to be included to version 0.3.1 - which I suppose will be available soon - so that we can have a true Greek character support with punctuation issues and other stuff. The link is the following http://www.reactos.org/bugzilla/show_bug.cgi?id=1831 And a screenshot with proof of it in action is here http://img148.imageshack.us/my.php?image=greekku9.jpg Thnx in advance!

18 years, 9 months

1
0
0 0

Gdi function Polygon

by Timo Kreuzer

Hi, Recently I have started reading Feng Yuan - Windows Graphics Programming Win32 GDI and found that this is a very interesting part of Windows / ReactOS I'd like to take a closer look to. I started to have a look at this when I noticed 2 things, that made my desk.cpl don't work correctly in ROS: 1.) SetDCPenColor is not implemented (I am currently working on a usermode implemenatation, I have finished GetDCPenColor, GetDCBrushColor is the same, Set... will follow soon.) 2.) Polygon() didn't work as expected. I used it to draw a tiny triangle on a button, but it doesn't look correct. I first thought it was because the triangle was simply too small (didn't show the lowest pixel), but it was because it is redirected to NtGdiPolygon. (instead of calling NtGdiPolyPolyDraw, wich is the way it works in windows. NtGdiPolygon doesn't seem to exist in Windows, so it seems it's currently only a Kernelmode implementation of Polygon and NtGdiPolyPolyDraw seems not to be implemented in ROS yet). Polygon is exspected to automatically close the polygon, but NtGdiPolygon doesn't do this. I will have a closer look on this later and hope I can fix this. My questions: Is there a reason it doesn't do it? Should the closing of the Polygon (simply by adding the first coordinates at the end?) be done in the usermode function (wich is not existing yet) or in the current implementation in win32k? Looking at the gdi code I found out that some things (handle validation for example) seem to be different than in windows. F.e. the reuse counter seems to be ignored. I have written a small GdiTest app to analyse the diffences between Win and ROS (General app is ready, I will write test functions soon, maybe tomorrow) . I'll start by writing some test cases, that I think might fail on ROS. If there's someone who likes to help me writing tests I'd really appreaciate that, just let me know. Then there's another thing that I thought about: Windows has one list of gdiobjects shared between kernel and all processes, although handles are only valid for the process that has created them (only Stockobjects are global). That seems to be a bad idea, I didn't try it yet, but what if a usermode app zeroes out the complete gdi handle table? I guess Windows would crash. And there might be more dangoerous risks, because of that. So why is the table not implemented locally? Some thoughts: Global handle list: + less memory needed - big chance of crashing windows by usermode apps Local handle list - more memory needed + better chance of paging the memory (global list would never be paged as it is always in use) + no chance for a user app to crash windows or crash other apps by messing up the handle table + no more need to veryfy the process member in the handle table entry A shared memory section seems to be a real risky thing. It's big enough to put binary data there and it might be possible to make another process with higher privaliges execute that code.I first thought of the DC's AbortProc, but that is probaly handled by the kernel to not exceed user limits(?). Implementing the handle table locally would not beak any APIs. Only some system apps that use the GdiQueryTable and directly use the table would experience a slightly different behaviour: Only locally created handles would be accessable. Would there be a problem doing that? At last my usermode implementation of GetDCPenColor, I would like some feedback: #define GDI_HANDLE_UPPER_MASK 0xffff0000 #define GDI_HANDLE_GET_UPPER(h) \ (((ULONG_PTR)(h)) & GDI_HANDLE_UPPER_MASK) COLORREF GetDCPenColor(HDC hDC) { PGDI_TABLE_ENTRY pEntry = GdiHandleTable + GDI_HANDLE_GET_INDEX(hGdiObj); if(pEntry->KernelData != NULL) { ULONG Upper = GDI_HANDLE_GET_UPPER(hGdiObj) if ( Upper == GDI_HANDLE_GET_UPPER(pEntry->Type) && GDI_HANDLE_GET_TYPE(Upper) == GDI_OBJECT_TYPE_DC ) { if((HANDLE)((ULONG_PTR)pEntry->ProcessId & ~0x1) == CurrentProcessId) { DC_ATTR* pDCData = (DC_ATTR*)pEntry->UserData if(pDCData) { return pDCData->crPenClr; } } } } return CLR_INVALID; }

18 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [janderwald] 24951: - mea culpa - hominem est erratum

by Thomas Weidenmueller

> - mea culpa > - hominem est erratum which means? Unfortunately only a tiny fraction of all people can read Latin ;) - Thomas

18 years, 9 months

2
1
0 0

Tr: Re: [Winpcap-users] [Installer] Architecture detection ?

by Sylvain Petreolle

Thanks, adding this value set to x86 made the WinPcap installer start. I wonder where we should set this. Since ReactOS has only x86 for now, I guess we can add it to the default registry set (hivesys.inf) Kind regards, Sylvain Petreolle (aka Usurp) --- --- --- --- --- --- --- --- --- --- --- --- --- Run your favorite Windows apps with free ReactOS : http://www.reactos.org Listen to non-DRMised Music: http://www.jamendo.com

18 years, 9 months

1
0
0 0

Resource files

by stud1281＠freemail.gr

Hi guys. Can anyone take care of the resource files we have added to bugzilla? It's been long time since a commit was made for these ones. Thnx in advance

18 years, 9 months

2
1
0 0

ReactOS Newsletter

by Samuel serapion

I have been an active member of the ReactOS community for some time now. I discovered this project a few months before the 0.2.9 release and was instantly amazed by the smart people and amount of hard work that has gone into this project now spanning a decade. Everyone knows me in #reactos by the name "encoded". Qualifications: - I compile and test ros almost every day, report bugs and participate in developer discussions. - I'm an amature coder, student of computer engineering(www.pupr.edu) - I like to program(a lot), so I understand what's going on pretty well. - I also know a bit of HTML. Goals for the newsletter: Not just the "there where commits about this and that this week" type of publication, I want to write articles about how foo.dll and bar feature work in windows, their current state in ROS. I want to create a medium which gives people outside the close nit ReactOS community a sense of belonging, that sparks the interest of coders and people in general. A medium that actually reflects the current state of affairs in ros, tips, tricks, how tos and even recent bugs and regressions! Note: -I am a full time student and also have a job, so I would prefer a bi-weekly newsletter, but could also work in a weekly time frame if needed. -Those nice little articles about foo.dll and bar features will be dependant(specially the ros side of it) on devs helping out in writing them. -I LOVE REACTOS!!!

18 years, 9 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [fireball] 24848: i386BootDrive and i386BootPartition are ULONGs, and before saving a byte value they must be zeroed. Thanks to Magnus for identifying the problem.

by Alex Ionescu

fireball(a)svn.reactos.org wrote: > Author: fireball > Date: Mon Nov 27 00:46:45 2006 > New Revision: 24848 > > URL: http://svn.reactos.org/svn/reactos?rev=24848&view=rev > Log: > i386BootDrive and i386BootPartition are ULONGs, and before saving a byte value they must be zeroed. Ever heard of movzx? -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 9 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [greatlrd] 24834: 1. revers 24831 to 24833 userenv.h does not exists in ms psdk and shall move to folder include/ndk or include/reactos 2. do not create new private header, we already have one, but it is in wrong folder. 3. This header should have been move long time ago. 4. do not doing #include "userenv-priv.h" it will not found the header in syssetup/install

by Aleksey Bragin

I wish Magnus would mention that this commit ALSO includes patch from bug #1837. WBR, Aleksey Bragin. On Nov 26, 2006, at 1:39 PM, greatlrd(a)svn.reactos.org wrote: > Author: greatlrd > Date: Sun Nov 26 13:39:50 2006 > New Revision: 24834 > > URL: http://svn.reactos.org/svn/reactos?rev=24834&view=rev > Log: > 1. revers 24831 to 24833 userenv.h does not exists in ms psdk and > shall move to folder include/ndk or include/reactos > 2. do not create new private header, we already have one, but it is > in wrong folder. > 3. This header should have been move long time ago. > 4. do not doing #include "userenv-priv.h" it will not found the > header in syssetup/install > > > Removed: > trunk/reactos/dll/win32/userenv/userenv-priv.h > Modified: > trunk/reactos/dll/win32/syssetup/install.c > trunk/reactos/dll/win32/syssetup/syssetup.rbuild > trunk/reactos/dll/win32/userenv/precomp.h > trunk/reactos/dll/win32/userenv/userenv.rbuild > trunk/reactos/drivers/input/i8042prt/mouse.c > trunk/reactos/include/psdk/userenv.h > > Modified: trunk/reactos/drivers/input/i8042prt/mouse.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/input/ > i8042prt/mouse.c?rev=24834&r1=24833&r2=24834&view=diff > ====================================================================== > ======== > --- trunk/reactos/drivers/input/i8042prt/mouse.c (original) > +++ trunk/reactos/drivers/input/i8042prt/mouse.c Sun Nov 26 > 13:39:50 2006 > @@ -903,6 +903,9 @@ > UCHAR Value; > UCHAR ExpectedReply[] = { 0xFA, 0xAA, 0x00 }; > unsigned ReplyByte; > + ULONG Counter; > + > + I8042Flush(); > > if (! I8042Write(DevExt, I8042_CTRL_PORT, 0xD4) || > ! I8042Write(DevExt, I8042_DATA_PORT, 0xFF)) > @@ -915,7 +918,12 @@ > ReplyByte < sizeof(ExpectedReply) / sizeof(ExpectedReply[0]) > && Ok; > ReplyByte++) > { > - Status = I8042ReadDataWait(DevExt, &Value); > + Counter = 200; > + > + do { > + Status = I8042ReadDataWait(DevExt, &Value); > + } while (Status == STATUS_IO_TIMEOUT && Counter--); > + > if (! NT_SUCCESS(Status)) > { > DPRINT1("No ACK after mouse reset, status 0x%08x\n", >

18 years, 9 months

1
0
0 0

Weekly newsletter author

by Dana Burkart

I have been following the ReactOS project for a while now, and would like to write your newsletters for you. Qualifications: - I have enough time to write the newsletter once a week. - English is my first language, and I can write fairly well. - I like to program in my free time, so I understand what's going on pretty well. - I don't know if I can do the IRC, though. - I also know HTML. If I am not picked, that's alright, I just wanted to help you guys out... I would help out with the actual project, but I don't think my programming skill is that advanced.

18 years, 9 months

1
0
0 0

Boot Crash in Usb

by James Tabor

Hi, Real hardware, svn 24795, (ntoskrnl/fstub/disksup.c:1618) (drivers/network/ndis/ndis/hardware.c:112)(NdisMQueryAdapterResources) No allocated resources! (drivers/network/ndis/ndis/miniport.c:1424)(NdisIPnPStartDevice) MiniportInitialize() failed for an adapter. (ntoskrnl/ldr/loader.c:259) Could not open module file: \SystemRoot\System32\drivers\usbehci.sys (Status 0xc0000034) (ntoskrnl/io/pnpmgr/pnpmgr.c:2372) Initialization of service usbehci failed (Status c0000034) (drivers/usb/usbport/usbcore.c:15) Miniport 0x81239618 registered (drivers/usb/miniport/common/fdo.c:337) IRP_MJ_PNP / unknown minor function 0x8 (drivers/usb/miniport/sys/linuxwrapper.c:479) IoGetDmaAdapter done 0x8122E2B8, mapRegisterCount=2 (drivers/usb/usbport/hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 0: 80F010B8 80EFC3F3 (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (drivers/usb/miniport/sys/linuxwrapper.c:137) usbcore: Created system thread 48 (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 1: 80F01114 80EFC2F0 (drivers/usb/usbport/hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers/usb/usbport/../miniport/linux/pci_hal.c:13) pci_enable_device() called. .. (drivers/usb/miniport/common/fdo.c:337) IRP_MJ_PNP / unknown minor function 0x8 (drivers/usb/miniport/sys/linuxwrapper.c:479) IoGetDmaAdapter done 0x8122F458, mapRegisterCount=2 (drivers/usb/usbport/hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 2: 80F010B8 80EFC3F3 (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (drivers/usb/miniport/sys/linuxwrapper.c:137) usbcore: Created system thread 52 (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 3: 80F01114 80EFC2F0 (drivers/usb/usbport/hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers/usb/usbport/../miniport/linux/pci_hal.c:13) pci_enable_device() called... (drivers/usb/miniport/common/fdo.c:337) IRP_MJ_PNP / unknown minor function 0x8 (drivers/usb/miniport/sys/linuxwrapper.c:479) IoGetDmaAdapter done 0x812302A8, mapRegisterCount=2 (drivers/usb/usbport/hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 4: 80F010B8 80EFC3F3 (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (drivers/usb/miniport/sys/linuxwrapper.c:137) usbcore: Created system thread 56 (drivers/usb/miniport/sys/linuxwrapper.c:201) driver_register 5: 80F01114 80EFC2F0 (drivers/usb/usbport/hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers/usb/usbport/../miniport/linux/pci_hal.c:13) pci_enable_device() called... (drivers/usb/usbport/hub.c:1230) hub_thread startingEntered debugger on last-chance exception (Exception Code: 0xc0000005) (Page Fault) Memory at 0xCDCDCDF1 could not be read: Page not present. kdb:> bt Eip: <usbuhci.sys:65b4 (drivers/usb/miniport/common/pdo.c:132 (UsbMpPdoPnp))> Frames: <usbuhci.sys:5ac2 (drivers/usb/miniport/common/main.c:402 (DispatchPnp))> <ntoskrnl.exe:3a2b9 (ntoskrnl/io/iomgr/irp.c:1084 (IofCallDriver))> <ntoskrnl.exe:3f99b (ntoskrnl/io/pnpmgr/pnpmgr.c:941 (IopInitiatePnpIrp))> <ntoskrnl.exe:40455 (ntoskrnl/io/pnpmgr/pnpmgr.c:1750 (IopActionInterrogateDeviceStack))> <ntoskrnl.exe:40177 (ntoskrnl/io/pnpmgr/pnpmgr.c:969 (IopTraverseDeviceTreeNode))> <ntoskrnl.exe:4018c (ntoskrnl/io/pnpmgr/pnpmgr.c:983 (IopTraverseDeviceTreeNode))> <ntoskrnl.exe:401ae (ntoskrnl/io/pnpmgr/pnpmgr.c:1008 (IopTraverseDeviceTree))> <ntoskrnl.exe:418f7 (ntoskrnl/io/pnpmgr/pnpmgr.c:2543 (IopInvalidateDeviceRelations))> <ntoskrnl.exe:39a25 (ntoskrnl/io/iomgr/iowork.c:30 (IopWorkItemCallback))> <ntoskrnl.exe:256a6 (ntoskrnl/ex/work.c:162 (ExpWorkerThreadEntryPoint))> <ntoskrnl.exe:6cc92 (ntoskrnl/ps/thread.c:134 (PspSystemThreadStartup))> <ntoskrnl.exe:76fc2 (ntoskrnl/ke/i386/ctxswitch.S:258 (KiThreadStartup@156))> Okay so I did not update the new hives yet,,, so I did,,, (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x0, desired 0x3)! (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x0, desired 0x3)! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (subsystems/win32/csrss/api/wapi.c:75) CSR: Calling handler for type: 2001d. (subsystems/win32/csrss/api/wapi.c:77) CSR: API Number: 1d ServerID: 2 (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x0, desired 0x100000)! (base/system/winlogon/sas.c:88) RegOpenKeyEx() failed with error 2 (ntoskrnl/ps/process.c:686) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (subsystems/win32/csrss/api/wapi.c:75) CSR: Calling handler for type: 0. (subsystems/win32/csrss/api/wapi.c:77) CSR: API Number: 0 ServerID: 0 (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x0, desired 0x3)! (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x60000, desired 0xf0001)! (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x0, desired 0xe)! (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x0, desired 0xe)! (subsystems/win32/csrss/api/wapi.c:132) CSR: CsrpHandleConnectionRequest: Handling: 00B3FF98 (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (subsystems/win32/csrss/api/wapi.c:192) CSR: CsrpHandleConnectionRequest done (subsystems/win32/csrss/api/wapi.c:75) CSR: Calling handler for type: 6. (subsystems/win32/csrss/api/wapi.c:77) CSR: API Number: 6 ServerID: 0 (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x20000, desired 0x2000f)! (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x60000, desired 0x1f0001)! (drivers/base/bootvid/bootvid.c:278) Waiting for bootvid thread to finish. (drivers/base/bootvid/bootvid.c:281) Bootvid thread to finish. (./subsystems/win32/win32k/objects/dc.c:324) No InstalledDisplayDrivers value in service entry found (./subsystems/win32/win32k/objects/dc.c:479) FindDriverFileNames failed (dll/ntdll/ldr/utils.c:1197) LdrGetExportByName(): failed to find mxdMessage (dll/ntdll/ldr/utils.c:2022) Failed to create or open dll section of 'msacm.drv' (Status c0000135) (dll/ntdll/ldr/utils.c:2022) Failed to create or open dll section of 'midimap.drv' (Status c0000135) (ntoskrnl/mm/freelist.c:1209) Zeroed 239724 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 32 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 16 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 32 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 32 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 32 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 16 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 32 pages. (ntoskrnl/cm/registry.c:733) Hive is still in use (hc 0, rc 5) (ntoskrnl/cm/ntfunc.c:2784) CmiDisconnectHive() failed (Status c0000001) (ntoskrnl/se/semgr.c:1054) FIX caller rights (granted 0x0, desired 0x100000)! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (ntoskrnl/ps/thread.c:496) FIX PS SDs!! (subsystems/win32/csrss/api/wapi.c:75) CSR: Calling handler for type: 2002c. (subsystems/win32/csrss/api/wapi.c:77) CSR: API Number: 2c ServerID: 2 (ntoskrnl/mm/freelist.c:1209) Zeroed 12 pages. ./subsystems/win32/win32k/ntuser/focus.c:205 ./subsystems/win32/win32k/ntuser/focus.c:92 (ntoskrnl/mm/freelist.c:1209) Zeroed 24 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 972 pages. (ntoskrnl/mm/freelist.c:1209) Zeroed 480 pages. System locked up with, EnableUserModePnpManager() Failed! Rebooting now! and a OK button. Ha ha real funny! Now can the joker but it back so it will work. James

18 years, 10 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [ekohl] 24792: Remove the obsolete STDCALL decorations from .def files.

by Alex Ionescu

ekohl(a)svn.reactos.org wrote: > Author: ekohl > Date: Mon Nov 20 00:17:42 2006 > New Revision: 24792 > > URL: http://svn.reactos.org/svn/reactos?rev=24792&view=rev > Log: > Remove the obsolete STDCALL decorations from .def files. I love you? I was JUST talking to Aleksey on how MSVC builds won't be linkable if this doesn't work. Please do this to every single .def file if you have time. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

18 years, 10 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [ion] 24773: - MSVC VCPROJ Maker: * Don't insert NDEBUG as a define, files define this manually already. * Don't add _CRT flags, since the RTM WDK defines them properly. * Force warning.h to be i ncluded just like the WDK does. * Disable WP

by Murphy, Ged (Bolton)

ion(a)svn.reactos.org wrote: > - Please remember that you NEED the WDK 6000 RTM installed to > use MSVC for building ReactOS. Don't change global build > settings just because you were too lazy to download it and > think that because your Win32 app doesn't need it, it's ok to > break other people's native/system/kernel/hal builds. Change > it locally if you're lazy, but don't revert these changes again. I highly dissagree that we should break building of usermode code in MSVC just because someone doesn't have 1 header file which is included with the WDK. If it effects the building of HAL etc so much, then it should be a requirement for those components only, not for wingui/win32dll code. Maybe including a similar header into our own code is a more viable option. Ged.

18 years, 10 months

3
2
0 0

Re: [ros-dev] [ros-diffs] [ion] 24767: - Purposefully add 6 debug prints to RtlpGetRegistryHandle, which, while ndis.sys is initializing, should BSOD the system. I have seen this "RtlpGetRegistryHandle" BSOD randomly during boot (But always with the same stack trace), and a local HAL patch managed to cause it 100% of the time. I know that the problem had nothing to do with the HAL or registry paths, because it came up before too when I added debug prints to fstub. These 6 prints 100% reproduce the problem o

by Reuel ben Yisrael

ion(a)svn.reactos.org wrote: > Author: ion > Date: Thu Nov 16 10:09:37 2006 > New Revision: 24767 > > URL: http://svn.reactos.org/svn/reactos?rev=24767&view=rev > Log: > - Purposefully add 6 debug prints to RtlpGetRegistryHandle, which, while ndis.sys is initializing, should BSOD the system. I have seen this "RtlpGetRegistryHandle" BSOD randomly during boot (But always with the same stack trace), and a local HAL patch managed to cause it 100% of the time. I know that the problem had nothing to do with the HAL or registry paths, because it came up before too when I added debug prints to fstub. These 6 prints 100% reproduce the problem on my machine with GCC 3.4.5. It is my hope it will do the same for everyone. This is a nasty bug, either stack related or some critical structure is being damaged. I am breaking trunk because it's been here for a long time, but now I found a way to repro it so that we can work together to try finding it. In a way, trunk was always broken, but this patch should force a freeze. Please help. > > Modified: > trunk/reactos/lib/rtl/registry.c > > Modified: trunk/reactos/lib/rtl/registry.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/registry.c?rev=247… > ============================================================================== > --- trunk/reactos/lib/rtl/registry.c (original) > +++ trunk/reactos/lib/rtl/registry.c Thu Nov 16 10:09:37 2006 > @@ -94,6 +94,11 @@ > } > > /* And now append the path */ > + DPRINT1("I'm about to crash due to an overwrite problem, Alex thinks\n"); > + DPRINT1("I'm about to crash due to a overwrite problem, Alex thinks\n"); > + DPRINT1("I'm about to crash due to a overwrite problem, Alex thinks\n"); > + DPRINT1("I'm about to crash due to a overwrite problem, Alex thinks\n"); > + DPRINT1("I'm about to crash due to a overwrite problem, Alex thinks\n"); > if (Path[0] == L'\\' && RelativeTo != RTL_REGISTRY_ABSOLUTE) Path++; // HACK! > Status = RtlAppendUnicodeToString(&KeyName, Path); > if (!NT_SUCCESS(Status)) return Status; > Where's # 6? I only see 5.. LOL

18 years, 10 months

1
0
0 0

Trunk is in frozen state

by Aleksey Bragin

Hello, trunk is frozen from any commits except for fixing that error mentioned in the last commit message ("ndis"-bug). Thanks for understanding, Aleksey Bragin.

18 years, 10 months

1
0
0 0

freetype cache

by Timo Kreuzer

Hi, Some time ago, I have done a small fix to make the freetype chache work. It still had the display bug with the original author (tinus) already experienced. I have fixed it now. As far as I have tested it is working correctly. And it speeds up text output by about 300%. Maybe someone should take a look at it. Bugzilla #511 Greetings, Timo

18 years, 10 months

3
4
0 0

Some feedback on ReactOS from LiveJournal

by Craig Talbert

http://community.livejournal.com/reactos/2373.html

18 years, 10 months

1
0
0 0

Re: [ros-dev] 0.3.1

by Murphy, Ged (Bolton)

Aleksey Bragin wrote: > There is an undecided problem: should we rebranch 0.3.1 or release it > as it is. I prefer rebranching from trunk, but that involves heavy > bugfixing of trunk, which I want to see any way. I don't know the state of 0.3.1 at the moment, but from what I remember it was quite stable. Why don't we just spend a day testing it to be sure and then release RC1. 0.3.2 could be branched directly after the 0.3.1 release. Ged.

18 years, 10 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev