Ros-dev November 2005

ros-dev@reactos.org

64 participants
176 discussions

RE: [ros-diffs] [jimtabor] 19536: Fix missed files. Svn problem?

by Casper Hornstrup

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 + */

19 years, 11 months

Re: [ros-svn] [sedwards] 19515: more msvc compile fixes by Brezenbak and I

by Hartmut Birr

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

19 years, 11 months

Re: [ros-svn] [gvg] 19517: Use inflib

by Thomas Weidenmueller

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

19 years, 11 months

Re: [ros-general] Re: Freeldr UI modifications

by João Jerónimo Barata de Oliveira

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/

19 years, 11 months

Faster compilation

by Casper Hornstrup

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

19 years, 11 months

PC poll

by Ged Murphy

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

19 years, 11 months

Java and Mono

by Rick Langschultz

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

19 years, 11 months

RE: [ros-diffs] [sedwards] 19482: porting fixes

by Casper Hornstrup

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

19 years, 11 months

Security Suite

by David Hinz

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

19 years, 11 months

RE: [ros-diffs] [cwittich] 19320: got a lot of crypt32 stuff working

by Casper Hornstrup

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.

19 years, 11 months

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

Jump to page:

2025

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