Ros-dev

ros-dev@reactos.org

5788 discussions

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.

18 years, 10 months

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

18 years, 10 months

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

18 years, 10 months

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

18 years, 10 months

Re: [ros-svn] [weiden] 19334: - define STATUS_* codes correctly in winnt.h and ntstatus.h

by James Tabor

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

18 years, 10 months

Announce mailing list, newsletter, TC & automated testing

by Drew Scott Daniels

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

18 years, 10 months

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)

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

18 years, 10 months

Re: [ros-diffs] [hbirr] 19329: - Changed all registry functions to WCHAR.

by Alex Ionescu

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

18 years, 10 months

[Fwd: [ros-general] BIOS]

by David Hinz

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 >

18 years, 10 months

Re: [ros-svn] [sedwards] 19259: created crt public headers directory. Moved excpt.h there

by Thomas Weidenmueller

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

18 years, 10 months

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