Ros-dev November 2006

ros-dev@reactos.org

32 participants
29 discussions

Re: [ros-dev] [ros-diffs] [ekohl] 24792: Remove the obsolete STDCALL decorations from .def files.
by Alex Ionescu 19 Nov '06

19 Nov '06

ekohl(a)svn.reactos.org wrote: > Author: ekohl > Date: Mon Nov 20 00:17:42 2006 > New Revision: 24792 > > URL: http://svn.reactos.org/svn/reactos?rev=24792&view=rev > Log: > Remove the obsolete STDCALL decorations from .def files. I love you? I was JUST talking to Aleksey on how MSVC builds won't be linkable if this doesn't work. Please do this to every single .def file if you have time. -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

2 1

Re: [ros-dev] [ros-diffs] [ion] 24773: - MSVC VCPROJ Maker: * Don't insert NDEBUG as a define, files define this manually already. * Don't add _CRT flags, since the RTM WDK defines them properly. * Force warning.h to be i ncluded just like the WDK does. * Disable WP
by Murphy, Ged (Bolton) 17 Nov '06

17 Nov '06

ion(a)svn.reactos.org wrote: > - Please remember that you NEED the WDK 6000 RTM installed to > use MSVC for building ReactOS. Don't change global build > settings just because you were too lazy to download it and > think that because your Win32 app doesn't need it, it's ok to > break other people's native/system/kernel/hal builds. Change > it locally if you're lazy, but don't revert these changes again. I highly dissagree that we should break building of usermode code in MSVC just because someone doesn't have 1 header file which is included with the WDK. If it effects the building of HAL etc so much, then it should be a requirement for those components only, not for wingui/win32dll code. Maybe including a similar header into our own code is a more viable option. Ged.

3 2

Re: [ros-dev] [ros-diffs] [ion] 24767: - Purposefully add 6 debug prints to RtlpGetRegistryHandle, which, while ndis.sys is initializing, should BSOD the system. I have seen this "RtlpGetRegistryHandle" BSOD randomly during boot (But always with the same stack trace), and a local HAL patch managed to cause it 100% of the time. I know that the problem had nothing to do with the HAL or registry paths, because it came up before too when I added debug prints to fstub. These 6 prints 100% reproduce the problem o
by Reuel ben Yisrael 16 Nov '06

16 Nov '06

ion(a)svn.reactos.org wrote: > Author: ion > Date: Thu Nov 16 10:09:37 2006 > New Revision: 24767 > > URL: http://svn.reactos.org/svn/reactos?rev=24767&view=rev > Log: > - Purposefully add 6 debug prints to RtlpGetRegistryHandle, which, while ndis.sys is initializing, should BSOD the system. I have seen this "RtlpGetRegistryHandle" BSOD randomly during boot (But always with the same stack trace), and a local HAL patch managed to cause it 100% of the time. I know that the problem had nothing to do with the HAL or registry paths, because it came up before too when I added debug prints to fstub. These 6 prints 100% reproduce the problem on my machine with GCC 3.4.5. It is my hope it will do the same for everyone. This is a nasty bug, either stack related or some critical structure is being damaged. I am breaking trunk because it's been here for a long time, but now I found a way to repro it so that we can work together to try finding it. In a way, trunk was always broken, but this patch should force a freeze. Please help. > > Modified: > trunk/reactos/lib/rtl/registry.c > > Modified: trunk/reactos/lib/rtl/registry.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/registry.c?rev=247… > ============================================================================== > --- trunk/reactos/lib/rtl/registry.c (original) > +++ trunk/reactos/lib/rtl/registry.c Thu Nov 16 10:09:37 2006 > @@ -94,6 +94,11 @@ > } > > /* And now append the path */ > + DPRINT1("I'm about to crash due to an overwrite problem, Alex thinks\n"); > + DPRINT1("I'm about to crash due to a overwrite problem, Alex thinks\n"); > + DPRINT1("I'm about to crash due to a overwrite problem, Alex thinks\n"); > + DPRINT1("I'm about to crash due to a overwrite problem, Alex thinks\n"); > + DPRINT1("I'm about to crash due to a overwrite problem, Alex thinks\n"); > if (Path[0] == L'\\' && RelativeTo != RTL_REGISTRY_ABSOLUTE) Path++; // HACK! > Status = RtlAppendUnicodeToString(&KeyName, Path); > if (!NT_SUCCESS(Status)) return Status; > Where's # 6? I only see 5.. LOL

1 0

Trunk is in frozen state
by Aleksey Bragin 16 Nov '06

16 Nov '06

Hello, trunk is frozen from any commits except for fixing that error mentioned in the last commit message ("ndis"-bug). Thanks for understanding, Aleksey Bragin.

1 0

freetype cache
by Timo Kreuzer 15 Nov '06

15 Nov '06

Hi, Some time ago, I have done a small fix to make the freetype chache work. It still had the display bug with the original author (tinus) already experienced. I have fixed it now. As far as I have tested it is working correctly. And it speeds up text output by about 300%. Maybe someone should take a look at it. Bugzilla #511 Greetings, Timo

3 4

Some feedback on ReactOS from LiveJournal
by Craig Talbert 15 Nov '06

15 Nov '06

http://community.livejournal.com/reactos/2373.html

1 0

Re: [ros-dev] 0.3.1
by Murphy, Ged (Bolton) 13 Nov '06

13 Nov '06

Aleksey Bragin wrote: > There is an undecided problem: should we rebranch 0.3.1 or release it > as it is. I prefer rebranching from trunk, but that involves heavy > bugfixing of trunk, which I want to see any way. I don't know the state of 0.3.1 at the moment, but from what I remember it was quite stable. Why don't we just spend a day testing it to be sure and then release RC1. 0.3.2 could be branched directly after the 0.3.1 release. Ged.

2 1

0.3.1
by Murphy, Ged (Bolton) 13 Nov '06

13 Nov '06

Any update on its progress? Release cycle speed doesn't seem to have improved since our last bungled attempt.

2 1

ReactOS doesn't boot
by Justin Haygood 12 Nov '06

12 Nov '06

Under Virtual PC 2007, ReactOS r24721 (as well as the last few over the last few days) simply do not boot. Boot CD: Boots, installs under text mode, stops when switching to GUI mode, has ntoskrnl.dll error in debug mode Live CD: Never finishes booting. Compiler: RosBE 0.3.1 (GCC 3.4.5) Does it boot for anyone else? If so, I'll attempt to figure out a way to get it to boot.

5 6

Re: [ros-dev] [ros-diffs] [ekohl] 24722: KbdLayerDescriptor is a STDCALL function.
by Aleksey Bragin 12 Nov '06

12 Nov '06

Actually "@X" were removed from all .def files to maintain compatibility with MSVC compiler, and GCC will do this silently with "--enable-stdcall-fixup" (which didn't work for some reason when enabled a few month ago). WBR, Aleksey Bragin. On Nov 11, 2006, at 11:33 PM, ekohl(a)svn.reactos.org wrote: > Author: ekohl > Date: Sat Nov 11 23:33:06 2006 > New Revision: 24722 > > URL: http://svn.reactos.org/svn/reactos?rev=24722&view=rev > Log: > KbdLayerDescriptor is a STDCALL function. > -=skip=- > Modified: trunk/reactos/dll/keyboard/kbdbe/kbdbe.def > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/keyboard/ > kbdbe/kbdbe.def?rev=24722&r1=24721&r2=24722&view=diff > ====================================================================== > ======== > --- trunk/reactos/dll/keyboard/kbdbe/kbdbe.def (original) > +++ trunk/reactos/dll/keyboard/kbdbe/kbdbe.def Sat Nov 11 23:33:06 > 2006 > @@ -4,5 +4,5 @@ > LIBRARY kbdbe.dll > > EXPORTS > -KbdLayerDescriptor > +KbdLayerDescriptor@0 > ;EOF -=skip=-

2 1

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 2006