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

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

18 years, 1 month

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)

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.

18 years, 1 month

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

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

18 years, 1 month

Trunk is in frozen state

by Aleksey Bragin

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.

18 years, 1 month

freetype cache

by Timo Kreuzer

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

18 years, 1 month

Some feedback on ReactOS from LiveJournal

by Craig Talbert

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

18 years, 1 month

Re: [ros-dev] 0.3.1

by Murphy, Ged (Bolton)

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.

18 years, 1 month

0.3.1

by Murphy, Ged (Bolton)

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

18 years, 1 month

ReactOS doesn't boot

by Justin Haygood

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.

18 years, 1 month

Re: [ros-dev] [ros-diffs] [ekohl] 24722: KbdLayerDescriptor is a STDCALL function.

by Aleksey Bragin

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

18 years, 1 month

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