Ros-dev

ros-dev@reactos.org

5789 discussions

RE: [greatlrd] 19565: implement addbuffer to waveTheard. itcan play wave one time if it is same file in windows

by Ge van Geldorp

> 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

19 years, 7 months

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

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

19 years, 7 months

RE: [ros-diffs] [sedwards] 19564: Fix pch usage in most of the rest ofcrt.lib...

by Casper Hornstrup

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

19 years, 7 months

RE: [ros-diffs] [turner] 19541: Read the registry to set the wallpapermode in in WinSta.

by Casper Hornstrup

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

19 years, 7 months

RE: [ros-dev] RE: [ros-diffs] [turner] 19541: Read the registry t o set the wallpapermode in in WinSta.

by Murphy, Ged (Bolton)

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

19 years, 7 months

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, 7 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, 7 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, 7 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, 7 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, 7 months

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