Ros-dev November 2005

ros-dev@reactos.org

64 participants
176 discussions

by Ge van Geldorp

Our current release process is documented at http://www.reactos.org/wiki/index.php/Release_Management_Overview. With the outcome of the TC function description vote, we need to change it to incorporate the TC role in the release process. I'd like to propose the following changes: - change "Once the project coordinator signals that a release is to be made, dates are set for all three stages and the release process begins." to "Once the testing coordinator (in consultation with the release engineer) signals that a release is to be made, tentative dates are set for all three stages and the release process begins.". Rationale: TC involvement, dates are not fixed but dependent on blocker bugs. - change "At the time of feature freeze, the first release candidate is produced by the release engineer." to "At the time of feature freeze, a release preview is produced by the release engineer.". Rationale: "release candidate" is probably not the best term to describe the state of the .iso. "Beta" is confusing since we're in alpha. "Preview" seems a nice generic term. - change "Code freeze is the next stage of the release process." to "Code freeze, the next stage of the release process, is entered when the testing coordinator indicates that all blocker bugs in the release branch have been fixed.". Rationale: TC involvement. - change "At the time of code freeze, the second and final release candidate is produced by the release engineer." to "At the time of code freeze, a release candidate is produced by the release engineer.". Rationale: I think we can safely call this one a release candidate. Gé van Geldorp.

19 years, 1 month

RE: [hpoussin] 19463: Fix sublanguage IDs in .rc files:

by Ge van Geldorp

> From: hpoussin(a)svn.reactos.com > > Fix sublanguage IDs in .rc files: > - LANG_ENGLISH -> SUBLANG_ENGLISH_US > - LANG_JAPANESE -> SUBLANG_DEFAULT > - others -> SUBLANG_NEUTRAL For reference, this is the search order currently used by ReactOS (copied from Wine, I'm not claiming Windows uses this same exact search order too, haven't tested): 1. specified language 2. specified language with neutral sublanguage 3. neutral language with neutral sublanguage if no explicitly specified language 4. current thread locale language 5. user locale language 6. user locale language with neutral sublanguage 7. system locale language 8. system locale language with neutral sublanguage 9. LANG_ENGLISH/SUBLANG_DEFAULT If searching for all of these fails, the first resource item found in the resource file matching the resource type and resource id is used. You can find this in lib/ntdll/ldr/res.c function LdrFindResource_U(). GvG

19 years, 1 month

RE: [ros-dev] Change of Project Coordinator

by Murphy, Ged (Bolton)

Considering there were no objections to the job description now in the wiki, it would be good to get the ball rolling again on this and start up the 1 week discussion period. Can any candidates wishing to put their name forward for this role please do so. Current list includes: - Steven Edwards. http://www.reactos.org/wiki/index.php/ReactOS_Project_Coordinator -----Original Message----- From: Casper Hornstrup [mailto:ch@csh-consult.dk] Sent: 10 November 2005 10:41 To: 'ReactOS Development List' Subject: RE: [ros-dev] RE: Change of Project Coordinator Better draft and vote on the project coordinator description first. It's good to know the job description when you apply for a job ;-) Casper > -----Original Message----- > From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Murphy, Ged > (Bolton) > Sent: 10. november 2005 10:14 > To: 'ReactOS Development List' > Subject: [ros-dev] RE: Change of Project Coordinator > > Jason Filby wrote: > > > I've decided that now is the best time to step down as Project > > Coordinator. The process to vote for a new PC will be - as previously > > decided for this type of decision - that only registered committers > > can vote. > > > This topic seems to have died a death, so I'm bringing it back up now as the > new voting system is in place. > I was speaking to Steven last night who advised he is now available to run > as PC. > Can any other candidates put their name forward again for the 1 week > discussion period. > > 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

19 years, 1 month

Re: [ros-svn] [weiden] 19406: fixed the ProbeForWriteLargeInteger and ProbeForWriteUlargeInteger macros

by Thomas Weidenmueller

weiden(a)svn.reactos.com wrote: > fixed the ProbeForWriteLargeInteger and ProbeForWriteUlargeInteger macros I'm sorry, I meant to write ProbeForReadLargeInteger and ProbeForReadUlargeInteger. - Thomas

19 years, 1 month

RE:[cwittich] 19402: WINE 0.9.1 vendor drop

by Ge van Geldorp

> 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.

19 years, 1 month

RE: [ros-svn] [cwittich] 19403: import avifil32 from WINE 0.9.1

by Ge van Geldorp

> 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

19 years, 1 month

DLL registration during setup: new rbuild task?

by Ge van Geldorp

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.

19 years, 1 month

RE: [ros-dev] 0.3 release plan - Again

by Murphy, Ged (Bolton)

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

19 years, 1 month

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

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

19 years, 1 month

ReactOS not installable

by Hartmut Birr

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))>

19 years, 1 month

← Newer
1
...
5
6
7
8
9
10
11
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev November 2005