Ros-dev December 2008

ros-dev@reactos.org

29 participants
44 discussions

by Aleksey Bragin

Hi, Mozilla Firefox 2.0: install it, run it, then quit - total hang without KDBG or any exception, TAB+K doesn't work. Then, reboot - try to navigate via Start Menu to Applications -> Mozilla Firefox. Explorer will die with exception in dll/win32/user32/ misc/exticon.c:88 (find_entry_by_id). Maybe due to files corruption. WBR, Aleksey.

15 years, 8 months

Re: [ros-dev] [ros-diffs] [cgutman] 38297: Huge memtrack commit (part 1 of 2) - Add checking for proper tags - Enable memtrack by default - Display the conflicting entries when an error occurs - Remove pool* routines and replace with ex* routines

by Aleksey Bragin

On Dec 23, 2008, at 3:39 PM, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Tue Dec 23 06:39:55 2008 > New Revision: 38297 > > ====================================================================== > ======== > --- branches/aicom-network-fixes/drivers/network/tcpip/datalink/ > lan.c [iso-8859-1] (original) > +++ branches/aicom-network-fixes/drivers/network/tcpip/datalink/ > lan.c [iso-8859-1] Tue Dec 23 06:39:55 2008 > @@ -703,7 +703,7 @@ > UnicodeString.MaximumLength = Information->DataLength; > > String->Buffer = > - (PWCHAR)exAllocatePool( NonPagedPool, > + (PWCHAR)ExAllocatePool( NonPagedPool, > UnicodeString.MaximumLength + sizeof(WCHAR) ); Isn't that a typo? you change it the other way around everywhere else in tcpip.

15 years, 8 months

Re: [ros-dev] [ros-diffs] [tkreuzer] 38294: For some unknown reason wmc likes to include string.h from the wine folder and we cannot link it on linux hosts. This hack should hopefully resolve the issue.

by Colin Finck

tkreuzer(a)svn.reactos.org wrote: > For some unknown reason wmc likes to include string.h from the wine folder and we cannot link it on linux hosts. This hack should hopefully resolve the issue. Not that mysterious actually. The "include/reactos/wine" directory is shared among Wine host and target tools while "include/crt" contains target-only headers and thus it's only available for target components. Therefore #include_next cannot find any other "string.h" file, when you use it inside host tools. Furthermore, #include_next is a GCC-only thing, so we should avoid it wherever possible. To circumvent these problems and remove the hacks from the actual CRT/PSDK headers, I propose we i.e. add '#include <reactos/wine/string.h>' to the CRT "string.h" and do the appropriate thing for other files. This is the prettiest solution I can think of without editing a bunch of Wine files. Best regards, Colin

15 years, 8 months

[ros-diffs] [dgorbachev] 38170: Add a hack which allows to boot with Armenian language.

by Dmitry Gorbachev

Sooner or later, this problem should be solved somehow. And not only for Armenians, but also for other peoples of the world, who live without code pages.

15 years, 8 months

Re: [ros-dev] [ros-diffs] [sserapion] 38260: Fix EDITSTREAM structure

by Ged

This will be lost in a Wine update -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of sserapion(a)svn.reactos.org Sent: 22 December 2008 03:22 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [sserapion] 38260: Fix EDITSTREAM structure Author: sserapion Date: Sun Dec 21 21:22:05 2008 New Revision: 38260 URL: http://svn.reactos.org/svn/reactos?rev=38260&view=rev Log: Fix EDITSTREAM structure Modified: branches/ros-amd64-bringup/reactos/dll/win32/riched20/editor.c branches/ros-amd64-bringup/reactos/include/psdk/richedit.h Modified: branches/ros-amd64-bringup/reactos/dll/win32/riched20/editor.c URL: http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/dll/w… ============================================================================== --- branches/ros-amd64-bringup/reactos/dll/win32/riched20/editor.c [iso-8859-1] (original) +++ branches/ros-amd64-bringup/reactos/dll/win32/riched20/editor.c [iso-8859-1] Sun Dec 21 21:22:05 2008 @@ -1616,7 +1616,7 @@ data.string = string; data.length = strlen(string); data.pos = 0; - es.dwCookie = (DWORD)&data; + es.dwCookie = (DWORD_PTR)&data; es.pfnCallback = ME_ReadFromRTFString; ME_StreamIn(editor, SF_RTF | (selection ? SFF_SELECTION : 0), &es, FALSE); } @@ -1998,7 +1998,7 @@ return FALSE; gds.hData = GetClipboardData(cf); gds.nLength = 0; - es.dwCookie = (DWORD)&gds; + es.dwCookie = (DWORD_PTR)&gds; es.pfnCallback = dwFormat == SF_RTF ? ME_ReadFromHGLOBALRTF : ME_ReadFromHGLOBALUnicode; ME_StreamIn(editor, dwFormat|SFF_SELECTION, &es, FALSE); Modified: branches/ros-amd64-bringup/reactos/include/psdk/richedit.h URL: http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/inclu… ============================================================================== --- branches/ros-amd64-bringup/reactos/include/psdk/richedit.h [iso-8859-1] (original) +++ branches/ros-amd64-bringup/reactos/include/psdk/richedit.h [iso-8859-1] Sun Dec 21 21:22:05 2008 @@ -517,7 +517,7 @@ typedef struct _editstream { DWORD dwCookie; - DWORD dwError; + DWORD_PTR dwError; EDITSTREAMCALLBACK pfnCallback; } EDITSTREAM;

15 years, 8 months

Re: [ros-dev] [ros-general] I am taking a break...

by Alex Ionescu

I concur with James. Eric, I think what you meant to say is you don't have time to work on ReactOS in its current state -- ie: the slow, time-consuming procedures and behaviors that take up more than 50% of your free time. What if ReactOS provides you with your own branch, and the ReactOS project assumes the responsibility of merging your changes to trunk, performing the testing and regression testing. You might be afraid that your code will "rot" and that it would never make it inline, but I'm sure the people respect your work as much as I do and would make sure that things stay up to date (much like we sync with Wine). This would allow you to keep committing code, have your own branch which at least works for you, and we'd take care of merging. Your only real responsibility would be to "sync up" with trunk every once in a while -- could even be only ever 3 months, or if you notice something obvious that might affect you (RPC changes, WIDL changes, SCM etc). I know this may sound unfair to other developers, but as James pointed out, you deserve everyone's time, considering how much you've put in all this time. On 19-Dec-08, at 9:22 PM, James Tabor wrote: > Hi Eric! > Eric Kohl wrote: >> Hi! >> >> Effective immediately I am taking a break from working on ReactOS >> for an >> undetermined period of time. It may even be the end of my involvement >> with ReactOS. >> >> There are several reasons for me to quit but the most important one >> is >> lack of time. I have a pretty exhausting job and spend more than 2 >> hours >> a day to commute so there is not much time left to spend on ReactOS. >> So working on ReactOS happened on weekends only. >> >> After my latest patch was partially reverted, I decided that I am not >> willing to create and maintain a development branch for >> improvements to >> LSA and SAM. I am not willing to spend an hour or two each weekend >> for >> branch maintenance and debugging and another two or three hours for >> developing new code. It just does not make sense to me. >> >> Maybe I will be back one day, maybe I will not. Time will tell. >> >> Over and out! >> Eric >> > Your resignation is disapproved! You are an integral part of this > project. > > You are the last of the root members of this project. We need your > help > and if that means breaking ReactOS truck that is your right to do > so. We will > learn to live with it. I have followed your work for years and I > would like > to see you more. Based on your tenure with this project, this gives > you > rights, influences and guidance to this project. > > Please recommence with your changes, > James > _______________________________________________ > Ros-general mailing list > Ros-general(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-general Best regards, Alex Ionescu

15 years, 9 months

Job offer: Linux tool to create a valid Windows Registry hive file

by Martin v. Wittich

Hi, we are a software development company that develops and maintains a Linux-based server solution called IServ, designed for use in schools. We are in business since 2003, and there are currently about 370 schools in Germany using IServ as their portal server. One feature that we would like to integrate into our product is the possibility to customize the ntconfig.pol file. This file, located on the server's netlogon share, can deploy registry settings to Windows clients - it is especially important because it can deploy HKEY_LOCAL_MACHINE settings. This file is a binary registry hive. At the moment, we have to create this file manually with poledit.exe. We need a Linux program which can automatically generate this file. 1) It should read plain text files as input, for example an INF file. 2) The resulting policy file must work with Windows 2000 and XP x86 clients. It should be possible to easily test this by using the command "Load Hive" in Regedit. 3) The preferred programming language is Perl, C/C++ is also OK. Other languages should also be possible, but only after prior consultation (just to make sure nobody comes up with Java ;) ). 4) The resulting source code should be released as open source, e.g. under the GPL. We would like the program being finished in one month. We will pay you EUR 300 for it. If the program is very much work and you feel you need more money, submit us an offer. A Perl library to dump binary registry files to plain text: http://search.cpan.org/~jmacfarla/Parse-Win32Registry-0.30/ Attachments: ntconfig.pol - Our current policy. This must be generated automatically. ntconfig.pol.dump - Plain text dump of that file, generated with Parse::Win32Registry. winnt.adm - Template to edit our policy file with poledit.exe. Our homepage: http://iserv.eu (only in German, though) -- Yours sincerely, Martin v. Wittich IServ Falk & Ludwig GbR Rebenring 33 38106 Braunschweig Germany Telephone: +49 531 380 4450 E-Mail: martin.von.wittich(a)iserv.eu Internet: http://www.iserv.eu

15 years, 9 months

Re: [ros-dev] [ros-diffs] [dgorbachev] 38170: Add a hack which allows to boot with Armenian language.

by Aleksey Bragin

Dmitry - I think we don't have THAT many Armenian users (if any?) so that we have to apply such ugly hacks. On Dec 18, 2008, at 3:26 PM, dgorbachev(a)svn.reactos.org wrote: > Author: dgorbachev > Date: Thu Dec 18 06:26:52 2008 > New Revision: 38170 > > URL: http://svn.reactos.org/svn/reactos?rev=38170&view=rev > Log: > Add a hack which allows to boot with Armenian language. > > Modified: > trunk/reactos/boot/freeldr/freeldr/reactos/reactos.c > > Modified: trunk/reactos/boot/freeldr/freeldr/reactos/reactos.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/ > freeldr/reactos/reactos.c?rev=38170&r1=38169&r2=38170&view=diff > ====================================================================== > ======== > --- trunk/reactos/boot/freeldr/freeldr/reactos/reactos.c > [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/reactos/reactos.c > [iso-8859-1] Thu Dec 18 06:26:52 2008 > @@ -262,8 +262,11 @@ > rc = RegQueryValue(hKey, szIdBuffer, NULL, (PUCHAR) > szNameBuffer, &BufferSize); > if (rc != ERROR_SUCCESS) { > > - strcpy(szErrorOut, "ACP NLS Setting exists, but isn't > readable"); > - return(FALSE); > + //strcpy(szErrorOut, "ACP NLS Setting exists, but isn't > readable"); > + //return(FALSE); > + > + /* HACK */ > + wcscpy(szNameBuffer, L"c_1252.nls"); > } > > /* load ANSI codepage table */ > @@ -288,8 +291,11 @@ > rc = RegQueryValue(hKey, szIdBuffer, NULL, (PUCHAR) > szNameBuffer, &BufferSize); > if (rc != ERROR_SUCCESS) { > > - strcpy(szErrorOut, "OEMCP NLS setting exists, but isn't > readable"); > - return(FALSE); > + //strcpy(szErrorOut, "OEMCP NLS setting exists, but isn't > readable"); > + //return(FALSE); > + > + /* HACK */ > + wcscpy(szNameBuffer, L"c_437.nls"); > } > > /* load OEM codepage table */ >

15 years, 9 months

About @KfLowerIrql@4

by Fan Zhang

hi, i'm a newbie of ReacOS. I looked a piece of code in syscall.S which is come from 0.2.7 edtion. /* Raise IRQL to APC_LEVEL */ movl $1, %ecx call @KfRaiseIrql@4 could anybody help me explain why the function is decorated by @ in the head? and why transfer argument by ecx? Thank you ___________________________________________________________ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/

15 years, 9 months

Have anyone tried, stress prime on ReactOS?

by Ashuaria Lee

Hi, Guys(and Girls) did you heard about a program called "stress prime"? It was developed to calculate prime numbers. And it is very sensitive to small errors. Since it has some kinda detecting errors, many overclockers are using it to confirm overclocked H/W stability. Yes, I tried to run this program, just for fun, and surprise! The system is not overclocked, nor has problem when running stressprime on WindowsXP. The rounding error amount was huge. I saw the source code of the stress prime and I'm sorry it was assembly language, so I couldn't check what could make such prolem under ReactOS. It was all about the math, and I'm not good at both(asm,math) But, one thing sure, is something is not working properly(maybe kernel?) and it is affecting ReactOS stability. What is your opinion? any comments? -- Regards, Ashuaria Lee

15 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev December 2008