- Ros-dev - ReactOS.org

Re: [ros-diffs] [gvg] 19618: Sync to Wine-0_9_2:
by Ged Murphy 26 Nov '05

26 Nov '05

2 1

Re: [ros-diffs] [sgasiorek] 19624: fixed reference to PML_TransError
by Thomas Weidenmueller 26 Nov '05

26 Nov '05

sgasiorek(a)svn.reactos.com wrote: > + wprintf(PML_TransError(error, (WCHAR*)errbuf, sizeof(errbuf)/sizeof(WCHAR))); This typecast is kind of useless... - Thomas

1 0

Re: [ros-svn] [sgasiorek] 19570: - changed name of package library to package.dll
by James Tabor 26 Nov '05

26 Nov '05

Hi! sgasiorek(a)svn.reactos.com wrote: > - changed name of package library to package.dll > - fixed PML_TransError function (possibly fixes bug 730) > > > > Added files: > trunk/rosapps/packmgr/lib/package.xml > > Updated files: > trunk/rosapps/packmgr/cmd-line/rosget.xml > trunk/rosapps/packmgr/directory.xml > trunk/rosapps/packmgr/gui/main.c > trunk/rosapps/packmgr/gui/packmgr.xml > trunk/rosapps/packmgr/lib/es.rc > trunk/rosapps/packmgr/lib/main.cpp > trunk/rosapps/packmgr/lib/package.cpp > trunk/rosapps/packmgr/lib/package.h > trunk/rosapps/packmgr/lib/package.hpp > > Deleted files: > trunk/rosapps/packmgr/lib/packlib.xml > [CC] modules/rosapps/packmgr/cmd-line/main.c modules/rosapps/packmgr/cmd-line/main.c: In function `SetStatus': modules/rosapps/packmgr/cmd-line/main.c:123: error: too few arguments to function `PML_TransError' modules/rosapps/packmgr/cmd-line/main.c: In function `Install': modules/rosapps/packmgr/cmd-line/main.c:139: error: too few arguments to function `PML_TransError' modules/rosapps/packmgr/cmd-line/main.c:162: error: too few arguments to function `PML_TransError' modules/rosapps/packmgr/cmd-line/main.c: In function `Show': modules/rosapps/packmgr/cmd-line/main.c:186: error: too few arguments to function `PML_TransError' make[1]: *** [obj-i386/modules/rosapps/packmgr/cmd-line/main.o] Error 1 Thanks, James

2 1

FreeDos32 and ReactOS
by crashfourit 26 Nov '05

26 Nov '05

We could work with Freedos32 (http://freedos-32.sourceforge.net/) with for the dos implimentation. -- My DeviantArt.com page: http://crashfourit.deviantart.com/ My FanFiction.net bio page: http://www.fanfiction.net/u/726606/ My Blog: http://crashfourit.blogspot.com/ America's Debate: http://www.americasdebate.com/

2 2

Re: [ros-dev] Log off reboots!
by TwoTailedFox 25 Nov '05

25 Nov '05

No, the Shutdown/Restart and Log Off portions are in need of a re-write, AFAIK. Since Local User Accounts are not implemented yet, we cannot "Log Off" per se on ReactOS just yet. On 11/25/05, Alex Buell <alex.buell(a)munted.org.uk> wrote: > Has someone confused the Log off menu item with the Shutdown menu item? > When logging off, it reboots. Is this intended? > > -- > http://www.munted.org.uk > > Anyone that thinks an imaginary deity is going to protect them against > earthquakes and hurricanes needs psychiatric help. > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -- "I had a handle on life, but then it broke"

1 0

TAB+K -> ESC+K
by Royce Mitchell III 25 Nov '05

25 Nov '05

anybody have a problem with me changing Tab+K to Esc+K. I was working in command prompt and accidentally hit the combo when using tab completion. Thanks

2 2

RE: [greatlrd] 19565: implement addbuffer to waveTheard. itcan play wave one time if it is same file in windows
by Ge van Geldorp 25 Nov '05

25 Nov '05

> From: greatlrd(a)svn.reactos.com > > implement addbuffer to waveTheard. it can play wave one time > if it is same file in windows I guess you forgot to commit a header file: [CC] lib/mmdrv/wave.c lib/mmdrv/wave.c: In function `waveThread': lib/mmdrv/wave.c:94: error: syntax error before '*' token lib/mmdrv/wave.c:99: error: `pHdrSearching' undeclared (first use in this function) lib/mmdrv/wave.c:99: error: (Each undeclared identifier is reported only once lib/mmdrv/wave.c:99: error: for each function it appears in.) lib/mmdrv/wave.c:116: warning: implicit declaration of function `waveStart' GvG

2 1

Re: [ros-diffs] [sedwards] 19564: Fix pch usage in most of the rest of crt.lib. Stop the abuse of including io.h, stdio.h and a few others directly. Add a generic license header to those source files that were missing it. There is still a few other headers left to fix and a few files missing pch and license headers
by Alex Ionescu 25 Nov '05

25 Nov '05

Hi Steven, You should include -all- headers in the main PCH,and have the files include only the PCH. This will be much faster. Best regards, Alex Ionescu

1 0

RE: [ros-diffs] [sedwards] 19564: Fix pch usage in most of the rest ofcrt.lib...
by Casper Hornstrup 25 Nov '05

25 Nov '05

How useful ;-) Casper _____ From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of sedwards(a)svn.reactos.com Sent: 25. november 2005 19:07 To: ros-diffs(a)reactos.com Subject: [ros-diffs] [sedwards] 19564: Fix pch usage in most of the rest ofcrt.lib. Stop the abuse of including io.h,stdio.h and a few others directly. Add a generic license header tothose source files that were missing it. There is still a fewother headers left t Modified: trunk/reactos/lib/crt/io/chmod.c --- trunk/reactos/lib/crt/io/chmod.c 2005-11-25 17:13:40 UTC (rev 19563) +++ trunk/reactos/lib/crt/io/chmod.c 2005-11-25 18:05:42 UTC (rev 19564) @@ -1,9 +1,16 @@ +/* + * COPYRIGHT: See COPYING in the top level directory + * PROJECT: ReactOS system libraries + * FILE: lib/crt/?????? + * PURPOSE: Unknown + * PROGRAMER: Unknown + * UPDATE HISTORY: + * 25/11/05: Created + */

1 0

RE: [ros-diffs] [turner] 19541: Read the registry to set the wallpapermode in in WinSta.
by Casper Hornstrup 25 Nov '05

25 Nov '05

CreatedStyleNum? _____ From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of turner(a)svn.reactos.com Sent: 25. november 2005 05:15 To: ros-diffs(a)reactos.com Subject: [ros-diffs] [turner] 19541: Read the registry to set the wallpapermode in in WinSta. Read the registry to set the wallpaper mode in in WinSta. Modified: trunk/reactos/subsys/win32k/ntuser/misc.c _____ Modified: trunk/reactos/subsys/win32k/ntuser/misc.c --- trunk/reactos/subsys/win32k/ntuser/misc.c 2005-11-25 03:50:49 UTC (rev 19540) +++ trunk/reactos/subsys/win32k/ntuser/misc.c 2005-11-25 04:14:59 UTC (rev 19541) @@ -6,7 +6,7 @@ * FILE: subsys/win32k/ntuser/misc.c * PROGRAMER: Ge van Geldorp (ge(a)gse.nl) * REVISION HISTORY: - * 2003/05/22 Created + * 2003/05/22 CreatedStyleNum */ #include <w32k.h> @@ -928,7 +928,18 @@

2 1

RE: [ros-dev] RE: [ros-diffs] [turner] 19541: Read the registry t o set the wallpapermode in in WinSta.
by Murphy, Ged (Bolton) 25 Nov '05

25 Nov '05

lol, I was just thinking the same thing. -----Original Message----- From: Casper Hornstrup [mailto:ch@csh-consult.dk] Sent: 25 November 2005 10:01 To: ros-dev(a)reactos.org Subject: [ros-dev] RE: [ros-diffs] [turner] 19541: Read the registry to set the wallpapermode in in WinSta. CreatedStyleNum? _____ From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of turner(a)svn.reactos.com Sent: 25. november 2005 05:15 To: ros-diffs(a)reactos.com Subject: [ros-diffs] [turner] 19541: Read the registry to set the wallpapermode in in WinSta. Read the registry to set the wallpaper mode in in WinSta. Modified: trunk/reactos/subsys/win32k/ntuser/misc.c _____ Modified: trunk/reactos/subsys/win32k/ntuser/misc.c --- trunk/reactos/subsys/win32k/ntuser/misc.c 2005-11-25 03:50:49 UTC (rev 19540) +++ trunk/reactos/subsys/win32k/ntuser/misc.c 2005-11-25 04:14:59 UTC (rev 19541) @@ -6,7 +6,7 @@ * FILE: subsys/win32k/ntuser/misc.c * PROGRAMER: Ge van Geldorp (ge(a)gse.nl) * REVISION HISTORY: - * 2003/05/22 Created + * 2003/05/22 CreatedStyleNum */ #include <w32k.h> @@ -928,7 +928,18 @@ ************************************************************************ 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] [jimtabor] 19536: Fix missed files. Svn problem?
by Casper Hornstrup 25 Nov '05

25 Nov '05

Now the "FILE:" header line is wrong. A prime example that these lines get outdated. Casper _____ From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of jimtabor(a)svn.reactos.com Sent: 24. november 2005 23:09 To: ros-diffs(a)reactos.com Subject: [ros-diffs] [jimtabor] 19536: Fix missed files. Svn problem? Fix missed files. Svn problem? Added: trunk/reactos/drivers/multimedia/portcls/ Added: trunk/reactos/drivers/multimedia/portcls/portcls.c Added: trunk/reactos/drivers/multimedia/portcls/portcls.def Added: trunk/reactos/drivers/multimedia/portcls/portcls.h Added: trunk/reactos/drivers/multimedia/portcls/portcls.rc Added: trunk/reactos/drivers/multimedia/portcls/portcls.xml _____ Added: trunk/reactos/drivers/multimedia/portcls/portcls.c --- trunk/reactos/drivers/multimedia/portcls/portcls.c 2005-11-24 21:08:13 UTC (rev 19535) +++ trunk/reactos/drivers/multimedia/portcls/portcls.c 2005-11-24 22:08:38 UTC (rev 19536) @@ -0,0 +1,505 @@ +/* + * ReactOS PortCls Driver + * Copyright (C) 2005 ReactOS Team + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA + * + * COPYRIGHT: See COPYING in the top level directory + * PROJECT: ReactOS Sound System + * PURPOSE: Audio Port Class Functions + * FILE: drivers/dd/sound/portcls/portcls.c + * PROGRAMMERS: + * + * REVISION HISTORY: + * 21 November 2005 Created James Tabor + */

3 2

Re: [ros-svn] [sedwards] 19515: more msvc compile fixes by Brezenbak and I
by Hartmut Birr 24 Nov '05

24 Nov '05

sedwards(a)svn.reactos.com wrote: > more msvc compile fixes by Brezenbak and I > > > Hi, this change breaks compiling for me. I get the following error. - Hartmut: gcc -c lib\crt\float\chgsign.c -o .\up\obj-i386\lib\crt\float\chgsign.o -I.\up\obj-i386\lib\crt -Ilib\crt -Ilib\crt\include -D_DISABLE_TIDENTS -D__MINGW_IMPORT=extern -D__USE_W32API -D_WIN32_IE=0x600 -D_WIN32_WINNT=0x501 -D__REACTOS__ -DUSE_MSVCRT_PREFIX -D_MSVCRT_LIB_ -D_MSVCRT_ -D_MT -Iinclude -Iinclude\reactos -Iinclude\libs -Iinclude\drivers -Iinclude\subsys -Iinclude\ndk -Iw32api\include -Iw32api\include\crt -Iw32api\include\ddk -D_M_IX86 -D_X86_ -D__i386__ -DDBG -Wall -momit-leaf-frame-pointer -mpreferred-stack-boundary=2 -ftracer -Os -fno-strict-aliasing -fno-optimize-sibling-calls -Wpointer-arith -g -pipe -Werror gcc -c lib\crt\float\clearfp.c -o .\up\obj-i386\lib\crt\float\clearfp.o -I.\up\obj-i386\lib\crt -Ilib\crt -Ilib\crt\include -D_DISABLE_TIDENTS -D__MINGW_IMPORT=extern -D__USE_W32API -D_WIN32_IE=0x600 -D_WIN32_WINNT=0x501 -D__REACTOS__ -DUSE_MSVCRT_PREFIX -D_MSVCRT_LIB_ -D_MSVCRT_ -D_MT -Iinclude -Iinclude\reactos -Iinclude\libs -Iinclude\drivers -Iinclude\subsys -Iinclude\ndk -Iw32api\include -Iw32api\include\crt -Iw32api\include\ddk -D_M_IX86 -D_X86_ -D__i386__ -DDBG -Wall -momit-leaf-frame-pointer -mpreferred-stack-boundary=2 -ftracer -Os -fno-strict-aliasing -fno-optimize-sibling-calls -Wpointer-arith -g -pipe -Werror In file included from lib\crt\float\chgsign.c:1: lib/crt/include/float.h:94:1: "DBL_MAX_10_EXP" redefined In file included from lib/crt/include/float.h:19, from lib\crt\float\chgsign.c:1: e:/mingw/bin/../lib/gcc/mingw32/3.4.2/include/float.h:97:1: this is the location of the previous definition _make: *** [.\up\obj-i386\lib\crt\float\chgsign.o] Error 1 _make: *** Waiting for unfinished jobs.... In file included from lib\crt\float\clearfp.c:1: lib/crt/include/float.h:94:1: "DBL_MAX_10_EXP" redefined In file included from lib/crt/include/float.h:19, from lib\crt\float\clearfp.c:1: e:/mingw/bin/../lib/gcc/mingw32/3.4.2/include/float.h:97:1: this is the location of the previous definition _make: *** [.\up\obj-i386\lib\crt\float\clearfp.o] Error 1

1 0

Re: [ros-svn] [gvg] 19517: Use inflib
by Thomas Weidenmueller 24 Nov '05

24 Nov '05

gvg(a)svn.reactos.com wrote: > Use inflib I can no longer link usetup compiled with gcc4: obj-i386\lib\inflib\inflib.a(infcore.o): In function `leading_spaces_state': C:/MingW/include/ctype.h:151: undefined reference to `_imp____mb_cur_max' C:/MingW/include/ctype.h:151: undefined reference to `_isctype' C:/MingW/include/ctype.h:151: undefined reference to `_imp____mb_cur_max' C:/MingW/include/ctype.h:151: undefined reference to `_imp___pctype' C:/MingW/include/ctype.h:151: undefined reference to `_isctype' obj-i386\lib\inflib\inflib.a(infcore.o): In function `trailing_spaces_state': C:/MingW/include/ctype.h:151: undefined reference to `_imp____mb_cur_max' C:/MingW/include/ctype.h:151: undefined reference to `_isctype' C:/MingW/include/ctype.h:151: undefined reference to `_imp____mb_cur_max' C:/MingW/include/ctype.h:151: undefined reference to `_imp___pctype' C:/MingW/include/ctype.h:151: undefined reference to `_isctype' obj-i386\lib\inflib\inflib.a(infcore.o): In function `line_start_state': C:/MingW/include/ctype.h:151: undefined reference to `_imp____mb_cur_max' C:/MingW/include/ctype.h:151: undefined reference to `_isctype' C:/MingW/include/ctype.h:151: undefined reference to `_imp___pctype' obj-i386\lib\inflib\inflib.a(infcore.o): In function `key_name_state': C:/MingW/include/ctype.h:151: undefined reference to `_imp____mb_cur_max' C:/MingW/include/ctype.h:151: undefined reference to `_isctype' C:/MingW/include/ctype.h:151: undefined reference to `_imp___pctype' obj-i386\lib\inflib\inflib.a(infcore.o): In function `value_name_state': C:/MingW/include/ctype.h:151: undefined reference to `_imp____mb_cur_max' C:/MingW/include/ctype.h:151: undefined reference to `_isctype' C:/MingW/include/ctype.h:151: undefined reference to `_imp___pctype' obj-i386\lib\inflib\inflib.a(infcore.o): In function `eol_backslash_state': C:/MingW/include/ctype.h:151: undefined reference to `_imp____mb_cur_max' C:/MingW/include/ctype.h:151: undefined reference to `_isctype' C:/MingW/include/ctype.h:151: undefined reference to `_imp___pctype' mingw32-make: *** [output-i386\subsys\system\usetup\usetup.exe] Error 1 - Thomas

2 2

Re: [ros-general] Re: Freeldr UI modifications
by João Jerónimo Barata de Oliveira 24 Nov '05

24 Nov '05

Alex Ionescu wrote: > Here are some changes I made to Freeldr last night. Also to ntoskrnl and the HAL. Booting takes 4 seconds now and seems much faster, it probably is a bit too. > > http://www.relsoft.net/rosldr1.png > http://www.relsoft.net/rosldr2.png In my opinion, it was best before with more graphical design... Now it's just like NTLDR, nothing special... I even think you would better entirely change FreeLDR configuration... I don't like poly-bootloaders (for distinguishing from multiboot, which is a standard) that run from disk partitions... In my opinion, the ideal boot loader: MBR boot code (446 bytes)... loads some contents of the 1st cylinder of the disk (after the MBR sector, it's usually empty) Contents of that space: configuration of the boot loader (no config reading from partitions while running this first stage boot loader); executable that shows the menu accordingly to the config it should read; some routines (possibly modules) for loading specific OSs, becuase they aren't all started the same way; and parhaps an image in some format... MBR boot code would load (and jump to) the menu binary, which reads the config and builds the menu accordingly... after knowing the user decision, it would read the right routine for that OS... That routine would, then, do what it has to do (i.e. load the kernel, switch to protected mode if that's the case, etc) or just chainload to another partition's boot code (on filesystems that allow it)... Well, indeed there's a boot loader that works very much like this... GRUB uses that sector to store some parts of the program... but I don't know if it stores there the config and I think that would be essencial (because, in my opinion, a boot loader needs to be independent from operating systems so, for example, there could be configuration floppy disks for changing its configuration)... As Grub is very similar (or parhaps identic) to my description of the ideal boot loader, I would like you to chose Grub as ReactOS boot loader (either by modifying it's configuration or by installing it from scratch, depending on the pré-install configuration)... That is, of course, also making ReactOS multiboot-compilant if it isn't already (It doesn't look like that)... I don't claim to be a pioneer on those ideas... But I think you are following the same path as Microsoft (i.e. I am the main OS, chainload to my partition and then I can load other OSs if you want) and it's not good... I think a boot loader must be on its own place, and MBR (and those bytes between MBR and the partitions) is the right place for a boot loader... Finally, I'm merelly giving my opinion... if you think that there are other priorities, I understand that... of course you have many other things to implement/stabilise/improve... I'm not very skilled in programming, otherwise I would help... João Jerónimo _______________________________________________________ Yahoo! Acesso Grátis: Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/

2 1

Faster compilation
by Casper Hornstrup 23 Nov '05

23 Nov '05

Hi. I've been working on getting ReactOS to build faster. By compiling fewer, but larger source files (compilation units), we can build ReactOS much faster. I estimate that we can build ReactOS 200-300% faster if we do this. See the attached patch for kernel32 for an example. On my slow box (Windows), I get the following numbers: kernel32 (1 compilation unit per file): build time: 32 seconds space consumed by object files: 52MB kernel32 (fewer compilation units): build time: 11 seconds space consumed by object files: 14MB Another advantage is the less disk space requirements. I estimate ~700-800MB will be needed for object files after this change. Compare that to the 2GB that is needed today. Gé did some testing on Linux: kernel32 (1 compilation unit per file): build time: 11.3 seconds kernel32 (fewer compilation units): build time: 4.4 seconds Some issues: * You can't mix source code files with different file name extensions in the same compilation unit (currently only *.c is supported) * There must not be duplicate definitions in the same compilation unit even though it is spread over several source code files (duplicating code is bad practice anyway). * Like when you compile a big source file, memory usage during compilation is higher than when compiling several smaller source code files, one at a time. This puts a practical limit on how large the compilation unit can be. * Every source code file in the compilation unit is recompiled after a change to one or more source code files within the compilation unit. The time needed for linking may however be significantly less (due to the fewer, much smaller object files) so it may be faster in the end. * Pre-compiled headers are not easy to support, while at the same time maintaining compatibility with MSVC and one source code file per compilation unit mode. Currently PCHs are disabled for a module if the module has compilation units with more than one source code file in it. While compiling kernel32 as one big compilation unit, GCC required 60MB of virtual memory. What is an acceptable memory usage? It determines how large we can make the compilation units and affects how fast we can build ReactOS. Now we have 300+ modules that need to be split into compilation units. Are there any volunteers that wish to help with these tasks? Thoughts? Casper

2 2

PC poll
by Ged Murphy 23 Nov '05

23 Nov '05

Just a quick note to say I set up the Project Coordinator poll this morning. It appears the auto mail functionality isn't working. It can be found here : http://www.reactos.org/forum/viewtopic.php?t=1193

2 1

Java and Mono
by Rick Langschultz 23 Nov '05

23 Nov '05

I have been developing a port of Java and Mono for ReactOS. Is anyone doing this already???

5 9

RE: [ros-diffs] [sedwards] 19482: porting fixes
by Casper Hornstrup 23 Nov '05

23 Nov '05

Why not just remove it, if it isn't needed? _____ From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of sedwards(a)svn.reactos.com Sent: 23. november 2005 07:34 To: ros-diffs(a)reactos.com Subject: [ros-diffs] [sedwards] 19482: porting fixes porting fixes Modified: trunk/reactos/apps/utils/net/tracert/tracert.c _____ Modified: trunk/reactos/apps/utils/net/tracert/tracert.c --- trunk/reactos/apps/utils/net/tracert/tracert.c 2005-11-23 06:02:15 UTC (rev 19481) +++ trunk/reactos/apps/utils/net/tracert/tracert.c 2005-11-23 06:33:19 UTC (rev 19482) @@ -28,7 +28,7 @@ */ -#include <windows.h> +//#include <windows.h> #include <winsock2.h> #include <tchar.h> #include <stdio.h> @@ -726,7 +726,7 @@ */ int main(int argc, char* argv[]) { - if (!ParseCmdline(argc, _argv)) return -1; + if (!ParseCmdline(argc, argv)) return -1; Driver();

2 1

Security Suite
by David Hinz 23 Nov '05

23 Nov '05

As recently the discussion about a firewall and a virus-scanner came up again, I thought of a new thing, that is a bit different than the already known things. My idea is not to use a firewall and a virus-scanner, I want to create a new service, that may be configured by a gui, a console app or by other apps, that might use some of its features. This service should do the following things: - Having a look at the network traffic, which includes the following: - Controlling, which application may use the network connections - Controlling, how many traffic they cause, which could warn the user about suspicious actions - Watching the running processes for unusual events - Checking every file that is read or written for viruses - Scanning the http-traffic for ads and viruses But the most important thing for me is that if this service is shutdown without the user agreeing to that, which may be checked by ntoskrnl, the user should be informed about it and nearly all network traffic should be blocked. Then the network-card should be deactivated, all userprocesses should be paused and all drives should be checked for viruses. I think this is hard, but it will make it much harder for worms to spread, as they don't have the chance to deactivate our securitysuite and so they will be detected within two days and if they try to shutdown the securitysuite they have no chance to spread. That would be more secure than any other existing OS. This are just a few thoughts, feel free to change it the way you like it. Greets, David Hinz

9 15

RE: [ros-diffs] [cwittich] 19320: got a lot of crypt32 stuff working
by Casper Hornstrup 22 Nov '05

22 Nov '05

We cant send this back to Wine so were going to get lots of conflicts when synchronizing with Wine and thus wasting a lot of Gé's time. What is needed is to make the ReactOS environment more like Wine or submit patches to Wine to make the Wine environment more like Windows' environment. So removing WINE_EXCEPTION_FILTER is not the way to do it since then it won't work on Wine. ReactOS grew 40% in 2004 just because of reusing code from Wine, so sharing code is definitely beneficial to both ReactOS and Wine.

5 16

Call for discussion: release process
by Ge van Geldorp 22 Nov '05

22 Nov '05

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.

1 2

RE: [hpoussin] 19463: Fix sublanguage IDs in .rc files:
by Ge van Geldorp 22 Nov '05

22 Nov '05

> 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

1 0

RE: [ros-dev] Change of Project Coordinator
by Murphy, Ged (Bolton) 21 Nov '05

21 Nov '05

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

2 1

Re: [ros-svn] [weiden] 19406: fixed the ProbeForWriteLargeInteger and ProbeForWriteUlargeInteger macros
by Thomas Weidenmueller 21 Nov '05

21 Nov '05

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

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