- Ros-dev - ReactOS.org

by Alex Ionescu

gdalsnes(a)svn.reactos.com wrote: >my 1st > > >Added files: >branches/hardons1stbranch/ > >Updated files: >branches/hardons1stbranch/kapi.h >branches/hardons1stbranch/ntuser.h > >Deleted files: >branches/hardons1stbranch/debug.h >branches/hardons1stbranch/debug1.h > > > Hi, I thought our pre-established branching rules recommend using an actual meaningful branch name? Not a generic user branch, but a feature branch. Best regards, Alex Ionescu

20 years, 1 month

1
0
0 0

RE: [ros-svn] [gdalsnes] 16793: my 1st

by Casper Hornstrup

Can't you rename it to something that reflects its purpose? Casper > -----Original Message----- > From: ros-svn-bounces(a)reactos.com [mailto:ros-svn-bounces@reactos.com] On Behalf Of > gdalsnes(a)svn.reactos.com > Sent: 27. juli 2005 13:07 > To: ros-svn(a)reactos.com > Subject: [ros-svn] [gdalsnes] 16793: my 1st > > my 1st > > > Added files: > branches/hardons1stbranch/ > > Updated files: > branches/hardons1stbranch/kapi.h > branches/hardons1stbranch/ntuser.h > > Deleted files: > branches/hardons1stbranch/debug.h > branches/hardons1stbranch/debug1.h > > _______________________________________________ > Ros-svn mailing list > Ros-svn(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-svn

20 years, 1 month

2
1
0 0

Re: [ros-svn] [ion] 16727: - Message Queue Fix, resolves a number of application regressions (Total Commander works again, for example). Patch by Hartmut Birr. To be commited into 0.2.7 after more testing.

by Hartmut Birr

ion(a)svn.reactos.com wrote: > - Message Queue Fix, resolves a number of application regressions (Total Commander works again, for example). Patch by Hartmut Birr. To be commited into 0.2.7 after more testing. > > >Updated files: >trunk/reactos/subsys/win32k/ntuser/window.c > > > Hi, this fix wasn't for commiting, because it doesn't solve the real problem. The destroying of the message queues is intitiated by calling Win32kThreadCallback which calls MsqDestroyMessageQueue. After this call, it shouldn't exist anymore a window for this thread. - Hartmut

20 years, 1 month

2
1
0 0

Re: [ros-svn] [hbirr] 16758: Lock the handle table if we trying to get a pointer from a handle.

by Thomas Weidenmueller

hbirr(a)svn.reactos.com wrote: > Lock the handle table if we trying to get a pointer from a handle. These changes are incorrect. Please revert them. Actually, a handle lookup requires _no_ locks at all. If you don't believe me, read up Windows Internals (4th Edition). The algorithms to allocate subtables are implemented in such a way that it is impossible to page fault on a lookup. However, it is not allowed to do a lookup in a table unless attached to the process that owns it (except it is a global handle table). Best Regards, Thomas

20 years, 1 month

1
0
0 0

Mozilla Embedded locks in ROS r16740

by reactos

Hello all devs, I am running Mozilla-Embedded (same as BartPE) because I can not get the Mozilla Controll to work, usually this is alright, but since some weeks ago Moz-Embedded locks the computer after the shell says "You're embedded man..." and before the mainwindow starts. It usually took a long time for the mainwindow to start, but it used to work, and I think it takes aproximately the same time for the mouse (and the rest of the system) to lock in r16740. I do not get any error-messages, someone with debugging skills has to look at this. Mozilla embedded can be found here: http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6a/mozilla… Yours sincerely, Jaix Bly

20 years, 1 month

1
0
0 0

Re: [ros-diffs] [hbirr] 16714: - Removed R_EXTRA_STACK because R_EXTRA_STACK and R_STACK must have the same size.

by Royce Mitchell III

hbirr(a)svn.reactos.com wrote: >- Initialized an allocated block completely before release the lock. > >@@ -719,9 +725,9 @@ > > > { > if ( (NewBlock = RQueRemove ( &pool->Que[que][align] )) ) > { > > >- R_RELEASE_MUTEX(pool); > > > RiUsedInit ( NewBlock, Tag ); > RiUsedInitRedZone ( NewBlock, NumberOfBytes ); > > >+ R_RELEASE_MUTEX(pool); > > > return RHdrToBody(NewBlock); > } > queBytes = 16 << que; >@@ -865,11 +871,10 @@ > > > NewBlock = (PR_USED)BestBlock; > RiUsedInit ( NewBlock, Tag ); > > > >- R_RELEASE_MUTEX(pool); >- > > > /* RtlZeroMemory(RHdrToBody(NewBlock), NumberOfBytes);*/ > > RiUsedInitRedZone ( NewBlock, NumberOfBytes ); > > >+ R_RELEASE_MUTEX(pool); > > > > return RHdrToBody(NewBlock); > } > > Hartmut, If you don't mind, I'm curious how this was causing a problem, the stuff that was being initialized outside of the lock shouldn't (in my feeble mind) have been "visible" upon reentry until this block is freed again. Thanks, Royce

20 years, 1 month

2
1
0 0

win32k message queue problem

by Hartmut Birr

Hi, it seems there exist a problem with the message queues. If a process is terminated (killed) from outside, the thread message queue is deleted before the last window is deleted. If there is a message (key or mouse) for this window, the window does access the already freed message queue. This will crash the system. Possible it is related to the paged pool memory corruption bug. I've a (dirty) fix for this problem. - Hartmut Index: subsys/win32k/ntuser/window.c =================================================================== --- subsys/win32k/ntuser/window.c (Revision 16707) +++ subsys/win32k/ntuser/window.c (Arbeitskopie) @@ -1577,6 +1577,7 @@ IntSetMenu(WindowObject, hMenu, &MenuChanged); } WindowObject->MessageQueue = PsGetWin32Thread()->MessageQueue; + IntReferenceMessageQueue(WindowObject->MessageQueue); WindowObject->Parent = (ParentWindow ? ParentWindow->Self : NULL); if((OwnerWindow = IntGetWindowObject(OwnerWindowHandle))) { @@ -2180,7 +2181,7 @@ if (Window->MessageQueue->CaptureWindow == Window->Self) Window->MessageQueue->CaptureWindow = NULL; IntUnLockMessageQueue(Window->MessageQueue); - + IntDereferenceMessageQueue(Window->MessageQueue); /* Call hooks */ #if 0 /* FIXME */ if (HOOK_CallHooks(WH_CBT, HCBT_DESTROYWND, (WPARAM) hwnd, 0, TRUE))

20 years, 1 month

2
2
0 0

Off Topic: Programming Salaries...

by Rick Langschultz

Hey all, I am hiring an entry level web programmer for the winter and would like to know what you would suggest to be a good starting salary. We are a small company that deals with serving users with portal services, such as database portals, collaboration portals, e-learning portals, web services, and simple PHP + MySQL websites. What would you want to be paid? Please be reasonable cause I am going to base someones salary on these statistics. Also please only respond directly to me, not to this list. No use clogging it up. Thanks, Rick Langschultz

20 years, 1 month

1
0
0 0

ReactOS crash on vmware 4.5 when usb controller is enabled .

by Saveliy Tretiakov

(ntoskrnl\ke\main.c:284) --------------------------------------------------------------- (ntoskrnl\ke\main.c:285) ReactOS 0.3-SVN (Build 20050723-r16704) Used memory 65536Kb (ntoskrnl\mm\mminit.c:375) Kernel Stack Limits. InitTop = 0x800f5000, Init = 0x800f2000 (ntoskrnl\mm\mm.c:283) No current process (ntoskrnl\io\pnpmgr.c:1749) Initialization of service vmx_svga failed (Status c0000001) (ntoskrnl\ldr\loader.c:315) Could not open module file: \SystemRoot\System32\DRIVERS\usbuhci.sys (ntoskrnl\io\pnpmgr.c:1749) Initialization of service usbuhci failed (Status c0000001) (ntoskrnl\io\pnpmgr.c:1749) Initialization of service vmx_svga failed (Status c0000001) (ntoskrnl\ldr\loader.c:315) Could not open module file: \SystemRoot\System32\DRIVERS\usbuhci.sys (ntoskrnl\io\pnpmgr.c:1749) Initialization of service usbuhci failed (Status c0000001) (ntoskrnl\ldr\loader.c:315) Could not open module file: \SystemRoot\system32\drivers\ne2000.sys (ntoskrnl\io\pnpmgr.c:1749) Initialization of service Ne2000 failed (Status c0000001) (ntoskrnl\ldr\loader.c:315) Could not open module file: \SystemRoot\system32\drivers\i8042prt.sys (ntoskrnl\io\pnpmgr.c:1749) Initialization of service i8042prt failed (Status c0000001) (ntoskrnl\ldr\loader.c:315) Could not open module file: \SystemRoot\system32\drivers\i8042prt.sys (ntoskrnl\io\pnpmgr.c:1749) Initialization of service i8042prt failed (Status c0000001) (ntoskrnl\io\pnpmgr.c:1749) Initialization of service serial failed (Status c0000034) (ntoskrnl\io\pnpmgr.c:1749) Initialization of service serial failed (Status c0000034) (drivers\input\i8042prt\registry.c:215) Can't read registry: c0000034 (drivers\input\i8042prt\registry.c:226) Manually set defaults (drivers\input\i8042prt\registry.c:215) Can't read registry: c0000034 (drivers\input\i8042prt\registry.c:226) Manually set defaults (drivers\input\i8042prt\i8042prt.c:570) Basic keyboard detection failed: c00000b5 (ntoskrnl\io\pnpmgr.c:1749) Initialization of service serial failed (Status c0000034) (ntoskrnl\io\pnpmgr.c:1749) Initialization of service serial failed (Status c0000034) (ntoskrnl\io\pnpmgr.c:1749) Initialization of service vmx_svga failed (Status c0000001) (drivers\usb\cromwell\uhci\fdo.c:293) UHCI: unknown minor function 0x8 (drivers\usb\cromwell\sys\linuxwrapper.c:466) IoGetDmaAdapter done 0x8CD02938, mapRegisterCount=2 (drivers\usb\cromwell\uhci\uhci-hcd.c:2556) INF: drivers\usb\cromwell\uhci\uhci-hcd.c: USB Universal Host Controller Interface driver v2.1 (drivers\usb\cromwell\core\hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers\usb\cromwell\sys\linuxwrapper.c:201) driver_register 0: 9d0070b8 9d0008a4(drivers\usb\cromwell\core\usb.c:164) INF: drivers\usb\cromwell\core\usb.c: registered new driver hub (drivers\usb\cromwell\sys\linuxwrapper.c:137) usbcore: Created system thread 60 (drivers\usb\cromwell\sys\linuxwrapper.c:201) driver_register 1: 9d0070e0 9d000890(drivers\usb\cromwell\core\hcd-pci.c:74) usbcore: usb_hcd_pci_probe() called (drivers\usb\cromwell\core\/../linux/pci_hal.c:13) pci_enable_device() called... (drivers\usb\cromwell\core\/../linux/pci_hal.c:44) pci_resource_flags() called, x=0x0 (drivers\usb\cromwell\core\/../linux/pci_hal.c:21) pci_resource_start() called, x=0x0 (drivers\usb\cromwell\core\/../linux/pci_hal.c:33) pci_resource_len() called, x=0x0 (drivers\usb\cromwell\core\/../linux/pci_hal.c:86) request_region(): addr=0x1060, len=0x20 (drivers\usb\cromwell\core\/../linux/pci_hal.c:58) pci_set_drvdata() called... (drivers\usb\cromwell\core\hcd-pci.c:163) UnivHCI PCI-USB Controller (drivers\usb\cromwell\core\hcd-pci.c:183) irq 9, io base 00001060 (drivers\usb\cromwell\core\hcd.c:678) new USB bus registered, assigned bus number 1 (drivers\usb\cromwell\uhci\/../linux/pci_hal.c:33) pci_resource_len() called, x=0x0 (drivers\usb\cromwell\sys\linuxwrapper.c:249) schedule_timeout: 5 ms (drivers\usb\cromwell\sys\linuxwrapper.c:278) schedule DONE!!!!!! (drivers\usb\cromwell\sys\linuxwrapper.c:249) schedule_timeout: 1 ms (drivers\usb\cromwell\sys\linuxwrapper.c:278) schedule DONE!!!!!! (drivers\usb\cromwell\sys\linuxwrapper.c:795) pci_alloc_consistent() size=8196 (drivers\usb\cromwell\sys\linuxwrapper.c:626) pci_pool_create(): UHCD PCI Slot/uhci_td size 48, 85/page (4096 alloc) (drivers\usb\cromwell\sys\linuxwrapper.c:626) pci_pool_create(): UHCD PCI Slot/uhci_qh size 48, 85/page (4096 alloc) (drivers\usb\cromwell\uhci\uhci-hcd.c:2264) INF: drivers\usb\cromwell\uhci\uhci-hcd.c: detected 2 ports (drivers\usb\cromwell\sys\linuxwrapper.c:656) pci_pool_alloc() called, blocks already allocated=0 (drivers\usb\cromwell\sys\linuxwrapper.c:656) pci_pool_alloc() called, blocks already allocated=0 KeBugCheckWithTf at ntoskrnl\ke\catch.c:228 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. The problem seems to be caused by the following file: ntoskrnl.exe Technical information: *** STOP: 0x0000001E (0xc0000005,0x80059827,0x00000000,0x0000000b) *** ntoskrnl.exe - Address 0x80059827 base at 0x80000000, DateStamp 0x0 Page Fault Exception: 14(0) Processor: 0 CS:EIP 8:80059827 <ntoskrnl.exe:59827 (ntoskrnl/mm/marea.c:86 (MmIterateNextNode))> cr2 b cr3 22000 Proc: 8050a7d8 Pid: 4 <System> Thrd: 8050b1d0 Tid: 0 DS 10 ES 10 FS 30 GS 10 EAX: ffffffff EBX: 80699640 ECX: 800ef1a0 EDX: 9cf67fff EBP: 800f477c ESI: 00000000 ESP: 800f4700 EDI: 00076514 EFLAGS: 00210286 kESP 800f4700 kernel stack base 800f2000 Frames: <ntoskrnl.exe:59e59 (ntoskrnl/mm/marea.c:505 (MmFindGapBottomUp))> <ntoskrnl.exe:5a0b9 (ntoskrnl/mm/marea.c:638 (MmFindGap))> <ntoskrnl.exe:5a578 (ntoskrnl/mm/marea.c:957 (MmCreateMemoryArea))> <ntoskrnl.exe:54be5 (ntoskrnl/mm/cont.c:60 (MmAllocateContiguousAlignedMemory))> <hal.dll:2681 (hal/halx86/generic/dma.c:64 (HalAllocateCommonBuffer))> <ntoskrnl.exe:4302a (ntoskrnl/io/pnpdma.c:46 (IopAllocateCommonBuffer))> <usbuhci.sys:8eb3 (drivers/usb/cromwell/sys/linuxwrapper.c:663 (my_pci_pool_alloc))> <usbuhci.sys:3f2f (drivers/usb/cromwell/uhci/uhci-hcd.c:313 (uhci_alloc_qh))> <usbuhci.sys:7897 (drivers/usb/cromwell/uhci/uhci-hcd.c:2289 (uhci_start))> <usbcore.sys:45b3 (drivers/usb/cromwell/core/hcd-pci.c:193 (usb_hcd_pci_probe))> <usbuhci.sys:1202 (drivers/usb/cromwell/uhci/fdo.c:56 (InitLinuxWrapper))> <usbuhci.sys:152e (drivers/usb/cromwell/uhci/fdo.c:192 (UhciFdoStartDevice))> <usbuhci.sys:1627 (drivers/usb/cromwell/uhci/fdo.c:243 (UhciPnpFdo))> <usbuhci.sys:2a74 (drivers/usb/cromwell/uhci/uhci.c:269 (DispatchPnp))> <ntoskrnl.exe:414ff (ntoskrnl/io/irp.c:1080 (IofCallDriver))> <ntoskrnl.exe:4409b (ntoskrnl/io/pnpmgr.c:636 (IopInitiatePnpIrp))> <ntoskrnl.exe:30894 (ntoskrnl/io/device.c:145 (IopStartDevice))> <ntoskrnl.exe:45738 (ntoskrnl/io/pnpmgr.c:1733 (IopActionInitChildServices))> <ntoskrnl.exe:457cb (ntoskrnl/io/pnpmgr.c:1773 (IopActionInitAllServices))> <ntoskrnl.exe:44110 (ntoskrnl/io/pnpmgr.c:666 (IopTraverseDeviceTreeNode))> <ntoskrnl.exe:44143 (ntoskrnl/io/pnpmgr.c:680 (IopTraverseDeviceTreeNode))> <ntoskrnl.exe:44143 (ntoskrnl/io/pnpmgr.c:680 (IopTraverseDeviceTreeNode))> <ntoskrnl.exe:44186 (ntoskrnl/io/pnpmgr.c:706 (IopTraverseDeviceTree))> <ntoskrnl.exe:45834 (ntoskrnl/io/pnpmgr.c:1833 (IopInitializePnpServices))> <800B7BC0> <800B5428> <ntoskrnl.exe:6456 (ntoskrnl/ke/main.c:95 (KiSystemStartup))> <800B384E> <0> KeBugCheckWithTf at ntoskrnl\ke\catch.c:228 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. The problem seems to be caused by the following file: ntoskrnl.exe Technical information: *** STOP: 0x0000001E (0x80000003,0x80091527,0x00000000,0x00000000) *** ntoskrnl.exe - Address 0x80091527 base at 0x80000000, DateStamp 0x0

20 years, 1 month

2
1
0 0

services in livecd

by Saveliy Tretiakov

I found that SCM is not started in livecd. This is wrong imho (I use livecd to debug ROS and I need SCM). This small patch will fix this. Index: winlogon.c =================================================================== --- winlogon.c (revision 16707) +++ winlogon.c (working copy) @@ -593,6 +593,8 @@ DbgPrint("WL: Cannot switch to Winlogon desktop (0x%X)\n", GetLastError()); } + InitServices(); + /* Check for pending setup */ if (GetSetupType () != 0) { @@ -616,8 +618,6 @@ return 2; } - InitServices(); - #if 0 /* real winlogon uses "Winlogon" */ RtlInitUnicodeString((PUNICODE_STRING)&ProcessName, L"Winlogon");

20 years, 1 month

1
0
0 0

RE: [ros-dev] Re: Reactos.com problems

by Murphy, Ged (Bolton)

Agreed. This is a perfect opportunity to bring in the new website. -----Original Message----- From: mf [mailto:mf@mufunyo.net] Sent: 23 July 2005 11:27 To: ros-dev(a)reactos.com Cc: ros-general(a)reactos.com Subject: [ros-dev] Re: Reactos.com problems Ge van Geldorp wrote: > For the moment, I've moved the mailing lists to a backup box. I am not > moving the website, since it seems the attack was carried out via the > website (a vulnerability in one of the php script packages we use). > I'll put up a dummy page informing visitors. Am I the only one thinking this is the perfect moment to put up the new static webpage along with the new design *hint hint* ? _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

20 years, 1 month

1
0
0 0

Re: [ros-svn] [ion] 16675: - Freetype Update to 2.1.10. Reduces memory usage, increases speed and fixes drawing bugs.

by Steven Edwards

--- ion(a)svn.reactos.com wrote: > - Freetype Update to 2.1.10. Reduces memory usage, increases speed and fixes drawing bugs. > - Enable Bytecode. Weird_W's fonts finally look humanly readable. Turn it off. ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

20 years, 1 month

8
12
0 0

Re: [ros-svn] [ekohl] 16685: Add parameter checks.

by James Tabor

Hi, ekohl(a)svn.reactos.com wrote: > Add parameter checks. > > > Updated files: > trunk/reactos/lib/setupapi/cfgmgr.c > [CC] lib/setupapi/cfgmgr.c lib/setupapi/cfgmgr.c: In function `CM_Locate_DevNode_ExW': lib/setupapi/cfgmgr.c:991: error: `CM_LOCATE_DEVNODE_BITS' undeclared (first use in this function) lib/setupapi/cfgmgr.c:991: error: (Each undeclared identifier is reported only once lib/setupapi/cfgmgr.c:991: error: for each function it appears in.) make: *** [obj-i386/lib/setupapi/cfgmgr.o] Error 1 I found /w32api/include/ddk/cfgmgr32.h adding <ddk/cfgmgr32.h> did help, but it created more problems. Thanks, James

20 years, 1 month

2
1
0 0

Reactos.com unavailable

by Ge van Geldorp

There are strong indications that the reactos.com box got cracked. Unfortunately, I'm on vacation right now and unable to fix things. Since it is causing problems on the network it will be isolated, meaning no network traffic in or out. This will mean the website will go down and the mailing lists will become inactive. I'm sorry about this, but there is not much I can do for the next week. Ge van Geldorp.

20 years, 1 month

1
0
0 0

Re: [ros-svn] [ekohl] 16685: Add parameter checks.

by Thomas Weidenmueller

ekohl(a)svn.reactos.com wrote: > Add parameter checks. > > > Updated files: > trunk/reactos/lib/setupapi/cfgmgr.c > > _______________________________________________ > Ros-svn mailing list > Ros-svn(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-svn > lib\setupapi\cfgmgr.c: In function `CM_Locate_DevNode_ExW': lib\setupapi\cfgmgr.c:991: error: `CM_LOCATE_DEVNODE_BITS' undeclared (first use in this function) lib\setupapi\cfgmgr.c:991: error: (Each undeclared identifier is reported only o nce lib\setupapi\cfgmgr.c:991: error: for each function it appears in.) mingw32-make: *** [obj-i386\lib\setupapi\cfgmgr.o] Error 1

20 years, 1 month

1
0
0 0

UsbView Crash

by James Tabor

Hi! This is the latest from USBView. Not to bad. Everyone knows it was working yesterday. I did update the hivesys and reinstalled everything from the current svn, revision 16634. Clean rebuild. Thank, James (drivers/usb/cromwell/uhci/create.c:30) UHCI: IRP_MJ_CREATE (drivers/usb/cromwell/uhci/create.c:41) UHCI: open HCDx successfull (drivers/usb/cromwell/uhci/devctrl.c:76) USB: IRP_MJ_DEVICE_CONTROL dispatch (drivers/usb/cromwell/uhci/devctrl.c:89) USB: IOCTL_GET_HCD_DRIVERKEY_NAME (drivers/usb/cromwell/uhci/devctrl.c:76) USB: IRP_MJ_DEVICE_CONTROL dispatch (drivers/usb/cromwell/uhci/devctrl.c:89) USB: IOCTL_GET_HCD_DRIVERKEY_NAME (drivers/usb/cromwell/uhci/devctrl.c:109) USB: IOCTL_GET_HCD_DRIVERKEY_NAME retu rns 'PCI\VEN_1106&DEV_3104&SUBSYS_73401462&REV_82' Unhandled exception Address: 76673d70 C:\ReactOS\system32\SETUPAPI.dll CS:EIP 1b:76673933 DS 23 ES 23 FS 3b GS 23 EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 EBP: 0055f9e4 ESI: 00000000 ESP: 0055f9ec EDI: 00000000 EFLAGS: 00000212 Frames: 76660000+13d70 C:\ReactOS\system32\SETUPAPI.dll 400000+3f73 C:\ReactOS\usbview.EXE 400000+1ddc C:\ReactOS\usbview.EXE 400000+1ba1 C:\ReactOS\usbview.EXE 400000+188e C:\ReactOS\usbview.EXE 400000+16d0 C:\ReactOS\usbview.EXE 77e50000+53ece C:\ReactOS\system32\USER32.dll 77e50000+5409a C:\ReactOS\system32\USER32.dll 77e50000+3925f C:\ReactOS\system32\USER32.dll 77e50000+53ece C:\ReactOS\system32\USER32.dll 77e50000+54b7c C:\ReactOS\system32\USER32.dll 77e50000+376df C:\ReactOS\system32\USER32.dll 77e50000+38da3 C:\ReactOS\system32\USER32.dll 77e50000+38ec5 C:\ReactOS\system32\USER32.dll 400000+14a7 C:\ReactOS\usbview.EXE 400000+1417 C:\ReactOS\usbview.EXE 400000+457f C:\ReactOS\usbview.EXE 7c800000+2f105 C:\ReactOS\system32\KERNEL32.dll (drivers/usb/cromwell/uhci/uhci.c:484) UHCI: IRP_MJ_CLEANUP (drivers/usb/cromwell/uhci/close.c:30) UHCI: IRP_MJ_CLOSE

20 years, 1 month

1
1
0 0

Re: [ros-svn] [ion] 16660: Dmitry Philippov <shedon@mail.ru>:

by Hartmut Birr

ion(a)svn.reactos.com wrote: > Dmitry Philippov <shedon(a)mail.ru>: > > - Implemented FindFirstFileExW() and have removed InternalFindFirstFile() in /lib/kernel32/file/find.c, now FindFirstFileA (), FindFirstFileExA () and FindFirstFileW called FindFirstFileExW () > >NOTE: Filip has asked revision "16661" (the next one) to be done by him... sorry if this sounds silly, but please respect his wish :) > > >Updated files: >trunk/reactos/lib/kernel32/file/find.c > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > > The implemention of FindFirstFileExW is very buggy. On errors, the allocated buffers are not cleanup correctly. The fourth parameter is wrong in the call to RtlDosPathNameToNtPathName_U. It isn't possible to cast a unicode string to a directory structure. The using of the results from the call to RtlDosPathNameToNtPathName_U is wrong. The buffer from the returned directory structure isn't always null terminated. - Hartmut

20 years, 1 month

2
1
0 0

RE: [ros-dev] Pending 0.2.7 RC2

by Murphy, Ged (Bolton)

Robert k. <rob(a)koepferl.de> wrote: > Hi, > > since there was just one change to the branch 0.2.7 I did not yet > publish the RC2 version. I decided to wait until monday to publishing > RC2. > It seems RC1 is being forgotten about. I know this has been discussed a few times before, but can we not look into the possibility of branching off for releases in a different way. Although it means changing SVN URL for HEAD, is it not better to follow the path of branching a new HEAD and freezing the current address for the next release. This may help people to remember to concentrate more on bugfixes for the upcoming release and not on implementing new features to HEAD. I'd hate to see another buggy release like 0.2.6, which was possibly a regression on 0.2.5 Ged. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

20 years, 1 month

3
2
0 0

Pending 0.2.7 RC2

by Robert k.

Hi, since there was just one change to the branch 0.2.7 I did not yet publish the RC2 version. I decided to wait until monday to publishing RC2.

20 years, 1 month

9
9
0 0

ReactOS Homepage Design Suggestions (vote soon)

by Klemens Friedl

ReactOS Homepage Design Suggestions: I collected all homepage design suggestions that has been posted to the mailing list(s) and copy&paste it together. I hope this will be useful for the new ReactOS Homepage. If you also have created a design and you are not on this list please write a mail to the mailing list! I will call for a "homepage design vote" soon. All suggestions: Jason Filby http://reactos.com/newsite/reactos_index.html Hi all A new proposed frontpage for reactos.com can be found here: http://reactos.com/newsite/reactos_index.html None of the links go anywhere yet. ezPublish will be phased out and most of the content hosted in a wiki (editable only by people trusted in the project). The wiki/forums/blogs would require a bit of a face-lift so as to look similar. Comments? Cheers Jason http://reactos.com:8080/archives/public/ros-web/2005-March/000050.html Klemens Friedl <frik85> ReactOS design suggestion and "RosCMS" (simple CMS that generate static pages) example. http://frik85.fr.funpic.de/reactos/en/index.htm (HTML version) http://frik85.fr.funpic.de/reactos/xhtml/en/index.html (XHTML version) Original mail from mailing list (June 2005): New ReactOS homepage design suggestion: I created a new ros hp design today. What's your opinion about the design? -> http://frik85.fr.funpic.de/ros_newhp/ Klemens Friedl <frik85> PS: Maybe we can use it (or parts of it). http://reactos.com:8080/archives/public/ros-web/2005-June/000086.html Brandon Turner http://brandonturner.org/ROS/index.html Hey, I like Mikko's design as well as others did i think(?) for the new website. All he had the was picture i think, so i went ahead and made the picture into a website if you were planning on using the design this might save ya some time. http://brandonturner.org/ROS/index.html Brandon http://reactos.com:8080/archives/public/ros-web/2005-May/000083.html Mindflyer's design He took Mikko's design and redesign it. http://www.mufunyo.net/reactos/web/ Hiya, First preview of what's to come: http://www.mufunyo.net/reactos/web Have fun, mf. http://reactos.com:8080/archives/public/ros-web/2005-June/000107.html ScoTTie scotteh at netspace.net.au http://www.wizzer-it.com/scott/reactos/ Hey, Ive played a little bit around with the design you initially did and came up with this http://www.wizzer-it.com/scott/reactos/ it looks Pretty much the same bar some minor alignment changes and some fonts. Basiclly ive just removed all the unneeded nested tables. Ive also Tested it in IE6, Firefox 1.0.4, Opera 8 and Links and it seems to Work fine in all of them. -- ScoTTie http://reactos.com:8080/archives/public/ros-web/2005-June/000098.html jh replies at mrnobody.uklinux.net http://reactos.com:8080/pipermail/ros-web/attachments/20050614/624eb1e9/ros… Hi all, Please find attached a screen shot of a page made entirely without tables. The general style is a combination of frick85 and mf, altered somewhat by me. You will see the link high-light styles for both navigation bar (mouse activated) and page (keyboard activated). Note, that all links can be activated by mouse and keyboard. So jump in, pull it apart and let use all know your opinions. Regards, jh http://reactos.com:8080/archives/public/ros-web/2005-June/000131.html Best regards, Klemens Friedl <frik85> -- GMX DSL = Maximale Leistung zum minimalen Preis! 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

20 years, 1 month

9
9
0 0

Re: [ros-svn] [navaraf] 16661: Get rid of windows.h include in win32k. Fixes bug #666.

by TwoTailedFox

Hehe... Bug 666 in 16661... OK, I get the Joke ;) On 7/20/05, navaraf(a)svn.reactos.com <navaraf(a)svn.reactos.com> wrote: > Get rid of windows.h include in win32k. Fixes bug #666. > > > Updated files: > trunk/reactos/include/ndk/extypes.h > trunk/reactos/include/ndk/i386/ketypes.h > trunk/reactos/include/subsys/csrss/csrss.h > trunk/reactos/subsys/win32k/eng/xlate.c > trunk/reactos/subsys/win32k/ntuser/misc.c > trunk/reactos/subsys/win32k/ntuser/scrollbar.c > trunk/reactos/subsys/win32k/objects/text.c > trunk/reactos/subsys/win32k/w32k.h > trunk/reactos/w32api/include/basetyps.h > trunk/reactos/w32api/include/ddk/ddrawi.h > trunk/reactos/w32api/include/ddk/ddrawint.h > trunk/reactos/w32api/include/ddraw.h > trunk/reactos/w32api/include/oleacc.h > trunk/reactos/w32api/include/winuser.h > > _______________________________________________ > Ros-svn mailing list > Ros-svn(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-svn > -- "I had a handle on life, but then it broke"

20 years, 1 month

2
1
0 0

Re: [ros-svn] [ion] 16649: - Update ASM header file with more offsets.

by James Tabor

Hi! ion(a)svn.reactos.com wrote: > - Update ASM header file with more offsets. > > > Updated files: > trunk/reactos/ntoskrnl/include/internal/asm.h > [PCH] obj-i386/ntoskrnl/include/ntoskrnl.h.gch In file included from ntoskrnl/include/internal/ntoskrnl.h:14, from ntoskrnl/include/ntoskrnl.h:43: ntoskrnl/include/internal/asm.h:132:1: "CONTEXT_FULL" redefined In file included from w32api/include/windef.h:249, from w32api/include/ddk/ntddk.h:35, from ntoskrnl/include/ntoskrnl.h:18: w32api/include/winnt.h:1482:1: this is the location of the previous definition In file included from ntoskrnl/include/internal/ntoskrnl.h:14, from ntoskrnl/include/ntoskrnl.h:43: ntoskrnl/include/internal/asm.h:133:1: "CONTEXT_FLOATING_POINT" redefined In file included from w32api/include/windef.h:249, from w32api/include/ddk/ntddk.h:35, from ntoskrnl/include/ntoskrnl.h:18: w32api/include/winnt.h:1479:1: this is the location of the previous definition make: *** [obj-i386/ntoskrnl/include/ntoskrnl.h.gch] Error 1 Did I miss a memo or should I delete something to make this work? Thanks, James 8^>

20 years, 1 month

1
0
0 0

Re: [ros-svn] [greatlrd] 16563: Change some error msg from ConErr to ConOut for they are being pipe so the behover are equal with ms windows cmd

by Hartmut Birr

greatlrd(a)svn.reactos.com wrote: >Change some error msg from ConErr to ConOut for they are being pipe so the behover are equal with ms windows cmd > > > >Updated files: >trunk/reactos/subsys/system/cmd/error.c > >_______________________________________________ >Ros-svn mailing list >Ros-svn(a)reactos.com >http://reactos.com:8080/mailman/listinfo/ros-svn > > > > Hi, I think this change is wrong (also some parts from 16579). The error messages have always to go to the error output (STD_ERROR_HANDLE). - Hartmut

20 years, 1 month

2
3
0 0

Re: [ros-svn] [ion] 16635: - Fix nasty APC delivery bug (in case a Kernel-Mode Special APC still returned with a Normal Routine, the Normal Routine was called with incorrect values (Special Routines take PVOID* arguments, while Normal Routines do not!))

by Hartmut Birr

ion(a)svn.reactos.com wrote: > - Fix nasty APC delivery bug (in case a Kernel-Mode Special APC still returned with a Normal Routine, the Normal Routine was called with incorrect values (Special Routines take PVOID* arguments, while Normal Routines do not!)) > - Remove APC from list before setting it to non-inserted. > - Do proper thread termination piggybacking; terminate threads in user-mode as Hartmut correctly fixed. > > >Updated files: >trunk/reactos/ntoskrnl/ke/apc.c >trunk/reactos/ntoskrnl/ps/kill.c > > > Hi, I do not agree to this changes. For a non system thread, we use a kernel mode apc first, which uses a second user mode apc. This overhead isn't necessary. For system threads it isn't possible to use a kernel mode apc which calls PspExitThread. A system thread must terminate it self. It is only possible to help by marking a flag, setting an event or unwait the thread. - Hartmut

20 years, 1 month

2
1
0 0

RE: [ros-diffs] [chorns] 16647: Generate RPC interface headers inintermediate directory

by Casper Hornstrup

You need to "del include\idl\*.h" after this change. Casper

20 years, 1 month

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