- Ros-dev - ReactOS.org

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

[Fwd: [ros-general] BIOS]
by David Hinz 18 Nov '05

18 Nov '05

jh schrieb: > From dev mailing list archive > >> From bblaauw at home.nl Thu Nov 17 16:09:23 2005 >> From: bblaauw at home.nl (Bernd Blaauw) >> Date: Thu Nov 17 16:12:08 2005 >> Subject: [ros-dev] 0.3 release plan - Again >> >> Would "USB working" also mean "boot from USB" ? Not even MS allows this. >> Sadly no PC BIOS supports "boot from FireWire", like Apples do. Guess >> we'd need LinuxBIOS for that, as current motherboard manufacturers don't >> want to pay AMI/Phoenix/Award for including the "boot from firewire" >> >module. >> >> Bernd >> > > Would these be of any interest. > > http://freebios.sourceforge.net/ > > http://www.openbios.info/ > > I am not subscribed to the dev mailing list, so does anyone want to > pass this on. > > Regards, > jh > _______________________________________________ > ros-general mailing list > ros-general(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-general >

1 0

Re: [ros-svn] [sedwards] 19259: created crt public headers directory. Moved excpt.h there
by Thomas Weidenmueller 18 Nov '05

18 Nov '05

sedwards(a)svn.reactos.com wrote: > created crt public headers directory. Moved excpt.h there > > > Added files: > trunk/reactos/w32api/include/crt/ > trunk/reactos/w32api/include/crt/excpt.h > > Updated files: > trunk/reactos/ReactOS.xml > > Deleted files: > trunk/reactos/w32api/include/excpt.h This change or r19260 causes compiling with GCC4 to fail: [CC] apps\utils\ps\ps.c In file included from include/ndk/ntndk.h:52, from apps\utils\ps\ps.c:28: include/ndk/rtltypes.h:544: error: conflicting types for 'PEXCEPTION_HANDLER' w32api/include/crt/excpt.h:56: error: previous declaration of 'PEXCEPTION_HANDLER' was here mingw32-make: *** [obj-i386\apps\utils\ps\ps.o] Error 1 - Thomas

2 1

RE: [ros-dev] Re: [ros-diffs] [gedmurphy] 19312: Improve stopping control of the service
by Murphy, Ged (Bolton) 18 Nov '05

18 Nov '05

> -----Original Message----- > From: Thomas Weidenmueller [mailto:w3seek@reactos.com] > Sent: 18 November 2005 12:03 > To: ReactOS Development List > Subject: Re: [ros-dev] Re: [ros-diffs] [gedmurphy] 19312: > Improve stopping control of the service > > > Murphy, Ged (Bolton) wrote: > > This function is new to me. > Now that you're writing multithreaded code it's about time to learn > about these functions ;) > > > I'm just doing a bit of research on it now to better > understand it, but > > could you just give me a bit of background of the > difference between this, > > and using something like a mutex or CS, and why it's better in this > > scenario? > Of course you can use mutexes or critical sections, but for > this purpose > interlocked operations are much more lightweight because with > mutexes or > critical sections you'd have to protect the read operation as > well. The > Interlocked* functions basically guarantee that a certain > operation on a > variable shared by multiple threads is performed in an atomic > matter. I > probably should mention that reads are always atomic, so reading a > variable with the size smaller or equal as the size of a > general purpose > register does not need to be protected, writes however have > to be protected. > > You should read the following articles: > http://msdn.microsoft.com/library/default.asp?url=/library/en- > us/dllproc/base/interlocked_variable_access.asp > http://blogs.msdn.com/oldnewthing/archive/2004/09/15/229915.aspx Thanks for the info, much appreciated. I've been reading up on Interlocked Variable Access this morning and have now implemented it into the code. 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

1 0

RE: [ros-dev] Re: [ros-diffs] [gedmurphy] 19312: Improve stopping control of the service
by Murphy, Ged (Bolton) 18 Nov '05

18 Nov '05

> -----Original Message----- > From: Thomas Weidenmueller [mailto:w3seek@reactos.com] > Sent: 17 November 2005 23:38 > To: ReactOS Development List > Subject: Re: [ros-dev] Re: [ros-diffs] [gedmurphy] 19312: > Improve stopping control of the service > > > Ged Murphy wrote: > > Could you explain what you mean? > As you want to change the value of the variables which are used in a > multithreaded environment you need to used the Interlocked* > functions to > ensure an atomic change in all environments (UP, MP, ...), and also to > make sure it's portable. > > > Those variables are only modified within the base thread, all other > > threads just check the value and act upon it. > > Why would that not be thread safe? > You're assuming the code will only run on a x86 system. In > fact, as long > as the variables are aligned properly it is an atomic operation. But > don't forget the other architectures and possibly upcoming > technologies > based on x86 that could void this assumption. > > I have to admit that the code wouldn't break, even in circumstances > where the operation wouldn't be atomic, but technically the code still > isn't thread-safe this way. > > - Thomas This function is new to me. I'm just doing a bit of research on it now to better understand it, but could you just give me a bit of background of the difference between this, and using something like a mutex or CS, and why it's better in this scenario? Thanks, 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

2 1

RE: [ros-dev] Microsoft Office files in the trunk
by Murphy, Ged (Bolton) 18 Nov '05

18 Nov '05

Mike Swanson wrote: > In the branch of press-media, there are two documents currently. An MS > Word and MS PowerPoint document. > > I'm calling for SVN committers for _no more_ MS Office documents. They > are a proprietary format, of which not all the features are currently > known. I recommend instead the use of OASIS OpenDocument. Not only > does it save much space, but it also does not contain any secrets in > which need to be reverse engineered to discover. > [...] > > Please, for the good of the project, use the free OpenDocument format. > If not for the reason of being open or free, but simply for the fact > that it ensures that everybody will be able to view such documents (no > need to buy any pricey office suites here!). I disagree with this. I don't know how to use oo.o or variants, and I don't intend on learning something I have no interest in. I'm currently putting together a presentation for the speeches I have coming up on ReactOS. If a rule was put in place where we could only commit OpenDocument files, I would simply not put it into the repository and would instead share it with anyone who wanted it via email. This isn't because I'm being awkward, it's because I have no time or interest to learn a new office suite .... and I certainly don't want to install oo.o on my machine. I suppose it's this attitude which keeps MS Office up as a monopoly, which now make me realise why they don't want to support OpenDocument. ************************************************************************ 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 7

Re: [ros-diffs] [gedmurphy] 19312: Improve stopping control of the service
by Thomas Weidenmueller 17 Nov '05

17 Nov '05

gedmurphy(a)svn.reactos.com wrote: > Improve stopping control of the service > > @@ -137,14 +137,14 @@ > > { > case SERVICE_CONTROL_SHUTDOWN: /* fall through */ > case SERVICE_CONTROL_STOP: > > - bShutDownFlag = TRUE; > > + bShutDown = TRUE; > > UpdateStatus(SERVICE_STOP_PENDING, -1); > break; > case SERVICE_CONTROL_PAUSE: > > - bPauseFlag = TRUE; > > + bPause = TRUE; > > break; > case SERVICE_CONTROL_CONTINUE: > > - bPauseFlag = FALSE; > > + bPause = FALSE; You might want to use InterlockedExchange to make it thread-safe. - Thomas

2 2

RE: [ros-svn] [gvg] 19303: Wine-0_9_1 vendor import
by Ge van Geldorp 17 Nov '05

17 Nov '05

> From: gvg(a)svn.reactos.com > > Wine-0_9_1 vendor import "svn update" will probably fail, you'll need to delete lib\dplay + lib\dplayx and do a second "svn update". Sorry about this, there seems to be no way around it. GvG

4 5

Freeldr Question
by Alex Ionescu 17 Nov '05

17 Nov '05

Hi, Freeldr currently contains an ugly (imo) wrapper around the GUI where every drawing operation is supposed to have multiple "modes" (some fancy 3d gizmo whizmo GUI and the normal text-mode interface). I would really like to simply this interface and make the drawing operations much simpler and just draw, instead of going through all the hoops they do now. But before I do, does anyone have any objections? Is anyone working on fancy 3D GUI for Freeldr, or can I go ahead with my changes? Note nothing would change to the user, everything will look and act the exact same way as it does now. Best regards, Alex Ionescu

4 14

CodePage Reg Key Error at Boot
by James Tabor 17 Nov '05

17 Nov '05

Hi, I'm getting "Couldn't open CodePage registry key. With OK". I copied freeldr.sys and the rest and reinstall everything, including config files from hives. Installs and go. 1st install system, 2nd reboot ok run fine, and 3rd reboot and get the above error at freeldr. Revision: 18820 Node Kind: directory Schedule: normal Last Changed Author: cwittich Last Changed Rev: 18820 Thanks, James

3 9

Re: [ros-diffs] [cwittich] 19291: implemented CreateServiceA
by Thomas Weidenmueller 17 Nov '05

17 Nov '05

cwittich(a)svn.reactos.com wrote: > implemented CreateServiceA This implementation theoretically is wrong, at least in windows this is also done using RPC (see the .idl file, there should be methods for ansi and unicode). - Thomas

2 1

0.3 release plan - Again
by Steven Edwards 17 Nov '05

17 Nov '05

Hi All, My how history repeats itself. I would like to call for a feature freeze on Jan 1st with the approval of the Testing Coordinator. Although we have not had that many releases of the 0.2.x line I feel enough has changed to and that we need to bump to 0.3. Lets review some history 0.1.x - winhello 0.2.x - explorer and a few wine dlls 0.3.x - OpenGL games, Firefox, Mirc, OpenOffice, third party drivers, start of PnP, USB, Xbox support, Initial DirectX Support, etc For the record we really did not plan on all of this other stuff for 0.3 and a year ago most of us would have been happy with just Firefox and Mirc working under VMware and Qemu. In fact we were planning on that work for the 0.3 line to be included in 0.4 release. Which is great! I am happy to see that we have gone much further beyond our once limited goals. What I propose now is that everyone that has a open project try to either get it to a Alpha state by Jan 1st or admit that it just wont be ready for 0.3 and accept that. Current major works in progress: DirectX - GreatLord USB - Fireball PnP - hpoussin Ws2 - Ionescu msvcDDK - sedwards Can we get all of these in for 0.3? Ws2 is a showstopper for 0.3, USB at least for the Xbox in my mind is a showstopper as well. PnP would be really, really nice to have but if its not ready I think we should ship anyway and plan on doing a short run to 0.4 before we fully support PnP. DirectX I have no idea how close it is to working and my current pet project for MSVC/DDK and rbuild is not a feature. I would like to be able to build ReactOS with our DDK under msvc in the hopes of getting more developers to join the project and improve the quality of our code but I am happy to admit this is not a priority. So what does everyone think? Can we shot for a feeze for Jan 1st? How does Feb 1st sound for a release? Thanks Steven __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

8 8

[hpoussin] 19288: Second attempt to have a workingkeyboard and mouse at third reboot
by Ge van Geldorp 17 Nov '05

17 Nov '05

> From: hpoussin(a)svn.reactos.com > > Second attempt to have a working keyboard and mouse at third > reboot May fix bug 1018 It does. Thanks! GvG

1 0

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

17 Nov '05

> -----Original Message----- > From: Steven Edwards [mailto:steven_ed4153@yahoo.com] > Sent: 17 November 2005 04:35 > To: ros-dev(a)reactos.org > Subject: [ros-dev] 0.3 release plan - Again > > > So what does everyone think? Can we shot for a feeze for Jan > 1st? How does Feb 1st sound for a release? Considering the state of HEAD at the moment, I think we should be going for a feature freeze much sooner than this. 1st of Jan is quite a long way off and it would be difficult to make any headway, especially on networking which is our showstopper, until this is sorted. IMO, we should be calling for a feature freeze as soon as the TC is elected. If that feature freeze gets HEAD back in stable and usable condition quickly, and with a bit of collaboration on networking, we could even aim at going for a Christmas release for 0.3.0 ?? If we are only stating networking must run for qemu and vmware, then I don't think we are that far off. It's been running in these two environments, intermittently, for quite some time now. Stable networking on real hardware could be kept for the 0.3.1 release. -- my glass is half full ;) 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

1 0

RE: [ros-dev] RE: [ros-diffs] [cwittich] 19266: fix memory leak i n case of erro r
by Murphy, Ged (Bolton) 16 Nov '05

16 Nov '05

sorry ignore, I didn't read the full function. -----Original Message----- From: Murphy, Ged (Bolton) [mailto:MurphyG@cmpbatteries.co.uk] Sent: 16 November 2005 15:57 To: 'ros-dev(a)reactos.org' Subject: [ros-dev] RE: [ros-diffs] [cwittich] 19266: fix memory leak in case of erro r There is another here : HardwareIdW = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); if (!HardwareIdW) { SetLastError(ERROR_GEN_FAILURE); return FALSE; } -----Original Message----- From: cwittich(a)svn.reactos.com [mailto:cwittich@svn.reactos.com] Sent: 16 November 2005 15:54 To: ros-diffs(a)reactos.com Subject: [ros-diffs] [cwittich] 19266: fix memory leak in case of error fix memory leak in case of error Modified: trunk/reactos/lib/newdev/newdev.c _____ Modified: trunk/reactos/lib/newdev/newdev.c --- trunk/reactos/lib/newdev/newdev.c 2005-11-16 15:14:31 UTC (rev 19265) +++ trunk/reactos/lib/newdev/newdev.c 2005-11-16 15:53:16 UTC (rev 19266) @@ -66,6 +66,7 @@ FullInfPathW = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); if (!FullInfPathW) { + HeapFree(GetProcessHeap(), 0, HardwareIdW); SetLastError(ERROR_GEN_FAILURE); return FALSE; } ************************************************************************ 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 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 ************************************************************************ 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] [cwittich] 19266: fix memory leak in case of erro r
by Murphy, Ged (Bolton) 16 Nov '05

16 Nov '05

There is another here : HardwareIdW = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); if (!HardwareIdW) { SetLastError(ERROR_GEN_FAILURE); return FALSE; } -----Original Message----- From: cwittich(a)svn.reactos.com [mailto:cwittich@svn.reactos.com] Sent: 16 November 2005 15:54 To: ros-diffs(a)reactos.com Subject: [ros-diffs] [cwittich] 19266: fix memory leak in case of error fix memory leak in case of error Modified: trunk/reactos/lib/newdev/newdev.c _____ Modified: trunk/reactos/lib/newdev/newdev.c --- trunk/reactos/lib/newdev/newdev.c 2005-11-16 15:14:31 UTC (rev 19265) +++ trunk/reactos/lib/newdev/newdev.c 2005-11-16 15:53:16 UTC (rev 19266) @@ -66,6 +66,7 @@ FullInfPathW = HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); if (!FullInfPathW) { + HeapFree(GetProcessHeap(), 0, HardwareIdW); SetLastError(ERROR_GEN_FAILURE); return FALSE; } ************************************************************************ 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev