Ros-dev

ros-dev@reactos.org

5790 discussions

RE:[cwittich] 19402: WINE 0.9.1 vendor drop
by Ge van Geldorp 21 Nov '05

21 Nov '05

> From: cwittich(a)svn.reactos.com > > WINE 0.9.1 vendor drop > > Added files: > vendor/wine/dlls/avifil32/Wine-0_9_1/ Can you "svn copy svn://svn.reactos.org/vendor/wine/dlls/avifil32/current svn://svn.reactos.org/vendor/wine/dlls/avifil32/Wine-0_9_1" instead of re-adding the files to .../Wine-0_9_1? By using "svn copy" you establish a common ancestry between .../current and .../Wine-0_9_1. (Of course, you need to svn delete .../Wine-0_9_1 now before you can do the svn copy). Thanks, GvG.

3 3

RE: [ros-svn] [cwittich] 19403: import avifil32 from WINE 0.9.1
by Ge van Geldorp 21 Nov '05

21 Nov '05

> From: cwittich(a)svn.reactos.com > > import avifil32 from WINE 0.9.1 Another case where you should use "svn copy". The vendor import process is described here: http://www.reactos.org/wiki/index.php/Using_code_from_other_projects GvG

1 0

DLL registration during setup: new rbuild task?
by Ge van Geldorp 21 Nov '05

21 Nov '05

In Wine, you get a popup if your program tries to load a WebBrowser control. That popup asks you if you want to download the Mozilla control. This is implemented in shdocvw.dll. Since we use the same code in ReactOS, I expected to get the same popup, but it doesn't show, instead ibrowser (as an example of an app that tries to load a WebBrowser control) just says "Sorry - no web browser control could be loaded". The reason that it doesn't work the same as in Wine is that the DllRegisterServer() procedure of shdocvw.dll is never called during setup. If you manually register shdocvw.dll ("regsvr32 shdocvw.dll") you do get the popup. There are 2 ways to fix this: we could hack it and add the registry entries (class registration) to hivecls.inf, or we can properly implement DLL registration during (second stage) setup. Although I don't mind cutting a corner every now and then, in this case my preference is to implement DLL registration during setup. That means we'll need an .inf file to describe which DLLs need to be registered. Windows has a syssetup.inf file for this, with a [OleControlDlls] section listing the DLLs to register/install. We can of course manually maintain a syssetup.inf file in bootdata, but this means one more file to keep up to date when you add a module. So I was thinking, maybe we could add an 'autoregister="R"' (indicating setup should call DllRegisterServer(), "I" to indicate it should call DllInstall() and "B" to indicate it should call both) attribute to <module> in the .xml file. Then rbuild should be able to automatically generate a syssetup.inf file. We could go one step further and also generate the bootdata/packages/reactos.dff file in a similar way. So, does this sound like the correct approach? If so, would anyone be interested in implementing the rbuild side of things? I can take care of the stuff that needs to be done during setup, but I've never worked on rbuild before. Gé van Geldorp.

4 8

RE: [ros-dev] 0.3 release plan - Again
by Murphy, Ged (Bolton) 20 Nov '05

20 Nov '05

USB is not a prerequisite for 0.3.0 so you might have to hold your breath for a little while longer. -----Original Message----- From: David Johnson [mailto:davidjohnson.johnson@gmail.com] Sent: 17 November 2005 14:55 To: ReactOS Development List Subject: Re: [ros-dev] 0.3 release plan - Again I am waiting with bated breth for 0.3. I have a test system that is waiting for USB. As soon as USB is working I will put ROS on my real hardware for testing. I hope this will be a help to the group. ************************************************************************ 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

6 6

Re: [ros-diffs] [ion] 19352: - Reimplement Fast Mutex implementation in HAL/NT to be compatible with the real implementation. (Fast Mutex needs to raise IRQL).
by Hartmut Birr 20 Nov '05

20 Nov '05

ion(a)svn.reactos.com wrote: > - Reimplement Fast Mutex implementation in HAL/NT to be compatible with the real implementation. (Fast Mutex needs to raise IRQL). > - Implement ExEnterCriticalRegionAndAcquireFastMutexUnsafe and ExReleaseFastMutexUnsafeAndLeaveCriticalRegion. > - Make win32k use those two new functions so that it can continue running at PASSIVE_LEVEL. > - Remove CcBrokenMutex and use the new APIs instead. > - Implement and export ntoskrnl version of Fast Mutex > - Update headers for new fast-mutex definition and API exports. > - Fix RemoveEntryList in NDK. > - Add exfuncs.h to NDK. > - Fix path in mmtypes.h in NDK to be compatible to how it shoudl be included. > *Modified: trunk/reactos/hal/halx86/generic/fmutex.c* > --- trunk/reactos/hal/halx86/generic/fmutex.c 2005-11-19 21:07:25 UTC (rev 19351) > +++ trunk/reactos/hal/halx86/generic/fmutex.c 2005-11-19 22:13:35 UTC (rev 19352) > +VOID > +FASTCALL > +ExAcquireFastMutex(PFAST_MUTEX FastMutex) > > { > > - KeEnterCriticalRegion(); > - ExAcquireFastMutexUnsafe(FastMutex); > > + KIRQL OldIrql; > + > + /* Raise IRQL to APC */ > + OldIrql = KfRaiseIrql(APC_LEVEL); > + > + /* Decrease the count */ > + if (InterlockedDecrement(&FastMutex->Count)) > + { > + /* Someone is still holding it, use slow path */ > + FastMutex->Contention++; > + KeWaitForSingleObject(&FastMutex->Gate, > + WrExecutive, > + WaitAny, > + FALSE, > + NULL); > + } > + > + /* Set the owner and IRQL */ > + FastMutex->Owner = KeGetCurrentThread(); > + FastMutex->OldIrql = OldIrql; > > } > Hi, this piece of code is wrong. If we terminating a thread, which waits on something, we do unblock the thread. The thread must check, if it got the lock, if not it must wait again. - Hartmut

2 4

ReactOS not installable
by Hartmut Birr 20 Nov '05

20 Nov '05

Hi, I'm not able to install ReactOS from the current trunk. It seems, that the new FastMutex implementation is broken. - Hartmut lib\rtl\error.c:910) RTL: RtlNtStatusToDosErrorNoTeb(0xc0): no valid W32 error mapping (lib\rtl\error.c:910) RTL: RtlNtStatusToDosErrorNoTeb(0xc0): no valid W32 error mapping (subsys\win32k\ntuserAssertion 'InterlockedIncrement((PLONG)(&_locked)) == 1' failed at subsys\win32k\ntuser\msgqueue.c line 1318 KeBugAssertion 'InterlockedIncrement((PLONG)(&_locked)) == 1' failed at subsys\win32k\ntuser\msgqueue.c line 1318 KeBugC(drivers\fs\np\fsctrl.c:25) NpfsListeningCancelRoutine() called \window.c:581) thread cleanup: while destroy wCheckWithTf at ntoskrnl\ke\i386\exp.c:1236 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,0x8006a721,0x812324e8,0x8173ba28) *** ntoskrnl.exe - Address 0x8006a721 base at 0x80000000, DateStamp 0x0 Breakpoint Exception: 3(0) Processor: 0 CS:EIP 8:8006a721 <ntoskrnl.exe:6a721 ({standard input}:23 ())> cr2 81737dfc cr3 1f12d000 Proc: 80f9a050 Pid: 78 <csrss.exe> Thrd: 812324e8 Tid: b0 DS 23 ES 23 FS 30 GS 0 EAX: 00000000 EBX: 9dc08cde ECX: 9e2f8a18 EDX: 00000000 EBP: 9e2f8c60 ESI: 9dc116b0 ESP: 9e2f8be4 EDI: 8d709120 EFLAGS: 00000286 kESP 9e2f8be4 kernel stack base 9e2f6000 Frames: <win32k.sys:5ea58 (subsys/win32k/ntuser/msgqueue.c:1318 (co_MsqWaitForNewMessages))> <win32k.sys:58aa6 (subsys/win32k/ntuser/message.c:948 (co_IntWaitMessage))> <win32k.sys:58d3a (subsys/win32k/ntuser/message.c:1051 (NtUserGetMessage))> <ntoskrnl.exe:647ca ({standard input}:373 (KiSystemService))> <user32.dll:310d9 (lib/user32/windows/message.c:1169 (GetMessageW))>

1 0

Re: [ros-svn] [weiden] 19334: - define STATUS_* codes correctly in winnt.h and ntstatus.h
by James Tabor 20 Nov '05

20 Nov '05

Hi, We need to check RosApps too. Thanks, James [CC] modules/rosapps/sysutils/ctm/ctm.c In file included from include/ndk/umtypes.h:18, from include/ndk/ntndk.h:19, from modules/rosapps/sysutils/ctm/ctm.c:45: w32api/include/ntstatus.h:30:1: "DBG_EXCEPTION_HANDLED" redefined In file included from w32api/include/windef.h:253, from w32api/include/windows.h:49, from modules/rosapps/sysutils/ctm/ctm.c:35: w32api/include/winnt.h:251:1: this is the location of the previous definition In file included from include/ndk/umtypes.h:18, from include/ndk/ntndk.h:19, from modules/rosapps/sysutils/ctm/ctm.c:45: w32api/include/ntstatus.h:31:1: "DBG_CONTINUE" redefined In file included from w32api/include/windef.h:253, from w32api/include/windows.h:49, from modules/rosapps/sysutils/ctm/ctm.c:35: w32api/include/winnt.h:252:1: this is the location of the previous definition In file included from include/ndk/umtypes.h:18, from include/ndk/ntndk.h:19, from modules/rosapps/sysutils/ctm/ctm.c:45: w32api/include/ntstatus.h:34:1: "DBG_TERMINATE_THREAD" redefined In file included from w32api/include/windef.h:253, from w32api/include/windows.h:49, from modules/rosapps/sysutils/ctm/ctm.c:35: w32api/include/winnt.h:253:1: this is the location of the previous definition In file included from include/ndk/umtypes.h:18, from include/ndk/ntndk.h:19, from modules/rosapps/sysutils/ctm/ctm.c:45: w32api/include/ntstatus.h:35:1: "DBG_TERMINATE_PROCESS" redefined In file included from w32api/include/windef.h:253, from w32api/include/windows.h:49, from modules/rosapps/sysutils/ctm/ctm.c:35: w32api/include/winnt.h:254:1: this is the location of the previous definition In file included from include/ndk/umtypes.h:18, from include/ndk/ntndk.h:19, from modules/rosapps/sysutils/ctm/ctm.c:45: w32api/include/ntstatus.h:36:1: "DBG_CONTROL_C" redefined <Snip. ..> w32api/include/ntstatus.h:772:1: "STATUS_FLOAT_MULTIPLE_FAULTS" redefined In file included from w32api/include/windef.h:253, from w32api/include/windows.h:49, from modules/rosapps/sysutils/ctm/ctm.c:35: w32api/include/winnt.h:245:1: this is the location of the previous definition In file included from include/ndk/umtypes.h:18, from include/ndk/ntndk.h:19, from modules/rosapps/sysutils/ctm/ctm.c:45: w32api/include/ntstatus.h:773:1: "STATUS_FLOAT_MULTIPLE_TRAPS" redefined In file included from w32api/include/windef.h:253, from w32api/include/windows.h:49, from modules/rosapps/sysutils/ctm/ctm.c:35: w32api/include/winnt.h:246:1: this is the location of the previous definition In file included from include/ndk/umtypes.h:18, from include/ndk/ntndk.h:19, from modules/rosapps/sysutils/ctm/ctm.c:45: w32api/include/ntstatus.h:786:1: "STATUS_REG_NAT_CONSUMPTION" redefined In file included from w32api/include/windef.h:253, from w32api/include/windows.h:49, from modules/rosapps/sysutils/ctm/ctm.c:35: w32api/include/winnt.h:247:1: this is the location of the previous definition In file included from include/ndk/umtypes.h:18, from include/ndk/ntndk.h:19, from modules/rosapps/sysutils/ctm/ctm.c:45: w32api/include/ntstatus.h:1114:1: "STATUS_SXS_EARLY_DEACTIVATION" redefined In file included from w32api/include/windef.h:253, from w32api/include/windows.h:49, from modules/rosapps/sysutils/ctm/ctm.c:35: w32api/include/winnt.h:248:1: this is the location of the previous definition In file included from include/ndk/umtypes.h:18, from include/ndk/ntndk.h:19, from modules/rosapps/sysutils/ctm/ctm.c:45: w32api/include/ntstatus.h:1115:1: "STATUS_SXS_INVALID_DEACTIVATION" redefined In file included from w32api/include/windef.h:253, from w32api/include/windows.h:49, from modules/rosapps/sysutils/ctm/ctm.c:35: w32api/include/winnt.h:249:1: this is the location of the previous definition make: *** [obj-i386/modules/rosapps/sysutils/ctm/ctm.o] Error 1

2 1

Announce mailing list, newsletter, TC & automated testing
by Drew Scott Daniels 19 Nov '05

19 Nov '05

Hi, It'd be nice if the announcement mailing list was still used. I'd suggest announcing the weekly newsletter in order to keep the list alive between releases. Can the "splash" newsletter be marked as dead? I enjoyed splash's RSS feed. Even more I'd enjoy if the ReactOS (ros) newsletter could become part of kernel cousin or have alike services. The job of the TC came up recently, and thus automated testing. Does the wine test suite run on ReactOS (it runs on Windows and wine)? Would it's results be useful to the TC? Could it be extended? Maybe it needs to be supplemented by something else. Codeweavers have software for automated testing that may be worth looking at too. Drew Daniels Resume: http://www.boxheap.net/ddaniels/resume.html

2 3

RE: [ros-diffs] [ion] 19327: Due to CcRos's abusive usage and dep endency on our broken Fast Mutex implementation, Fast Mutex can't be fixe d until the Cc Rewrite is complete. Since that seems to take longer and w e've identified drivers which need the corre
by Murphy, Ged (Bolton) 19 Nov '05

19 Nov '05

lmao @ these function names ..... -----Original Message----- From: ion(a)svn.reactos.com [mailto:ion@svn.reactos.com] Sent: 18 November 2005 18:52 To: ros-diffs(a)reactos.com Subject: [ros-diffs] [ion] 19327: Due to CcRos's abusive usage and dependency on our broken Fast Mutex implementation, Fast Mutex can't be fixed until the Cc Rewrite is complete. Since that seems to take longer and we've identified drivers which need the correct F +VOID +FASTCALL +CcAcquireBrokenMutex(PFAST_MUTEX FastMutex); + +VOID +FASTCALL +CcReleaseBrokenMutex(PFAST_MUTEX FastMutex); + +BOOLEAN +FASTCALL +CcTryToAcquireBrokenMutex(PFAST_MUTEX FastMutex); + ************************************************************************ 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

1 0

Re: [ros-diffs] [hbirr] 19329: - Changed all registry functions to WCHAR.
by Alex Ionescu 18 Nov '05

18 Nov '05

hbirr(a)svn.reactos.com wrote: >- Changed all registry functions to WCHAR. >- Implemented packed/unpacked names for keys and values. >- Fixed the hash values for very short data. >- Fixed the debug build. >- Don't search for a serial mouse, if the port is used for debug prints. > Hi Hartmut, Microsoft have managed to write their Cm code in a very portable way so that the Hv* (Hive) and Cm* (NT Config Manager) APIs are very seperated. The result of this is that they've been able to share the registry code between the kernel and the boot loader. Is there any way we can do the same? Certaintly having two pieces of code that are very similar but have subtle differences creates only more avenues for bugs. (Casper, you agree?) Best regards, Alex Ionescu

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev