Ros-dev

ros-dev@reactos.org

5788 discussions

Re: [ros-dev] [ros-diffs] [pschweitzer] 38432: FsRtlInitializeLargeMcb: Initialize fast mutex gate

by Alex Ionescu

Use a guarded mutex instead -- you're confused with what's actually going on. Fast mutexes use events, Guarded mutexes use gates. Both are initialized by their respective Ke/Ex/InitializeFast/Guarded mutex. On 28-Dec-08, at 3:06 PM, pschweitzer(a)svn.reactos.org wrote: > Author: pschweitzer > Date: Sun Dec 28 14:06:08 2008 > New Revision: 38432 > > URL: http://svn.reactos.org/svn/reactos?rev=38432&view=rev > Log: > FsRtlInitializeLargeMcb: Initialize fast mutex gate > > Modified: > branches/pierre-fsd/ntoskrnl/fsrtl/largemcb.c > > Modified: branches/pierre-fsd/ntoskrnl/fsrtl/largemcb.c > URL: http://svn.reactos.org/svn/reactos/branches/pierre-fsd/ntoskrnl/fsrtl/large… > = > = > = > = > = > = > = > = > ====================================================================== > --- branches/pierre-fsd/ntoskrnl/fsrtl/largemcb.c [iso-8859-1] > (original) > +++ branches/pierre-fsd/ntoskrnl/fsrtl/largemcb.c [iso-8859-1] Sun > Dec 28 14:06:08 2008 > @@ -130,7 +130,9 @@ > IN POOL_TYPE PoolType) > { > Mcb->FastMutex = > ExAllocateFromNPagedLookasideList(&FsRtlFastMutexLookasideList); > + > ExInitializeFastMutex(Mcb->FastMutex); > + KeInitializeGate((PKGATE)&(Mcb->FastMutex->Gate)); > > FsRtlInitializeBaseMcb(&(Mcb->BaseMcb), PoolType); > } > Best regards, Alex Ionescu

15 years, 9 months

Implementing ReplaceFileW

by Dmitry Chapyshev

Hi, I imported function ReplaceFileW from Wine, but it do not work in ReactOS. RepleceFileW there do not pass 11 tests (kernel32_winetest file). I think, that a problem in call MoveFileEx. Somebody can help with it? Function in Wine: http://www.reactos.org/paste/index.php/2745/ Patch for ReactOS: http://www.reactos.org/paste/index.php/2744/ -- WBR, Dmitry Chapyshev

15 years, 9 months

[ros-diffs] [jimtabor] 38348: - Example of a thread overrun? HAX-Fixes wine cursoricon test.

by James Tabor

Hi ALL! Okay, not sure what is going on but here is the original output: Unhandled exception ExceptionCode: c0000005 Faulting Address: 682000 Address: 7c91e6ae C:\ReactOS\system32\ntdll.dll CS:EIP 1b:7c91e6ae DS 23 ES 23 FS 3b GS 0 EAX: 011f0020 EBX: 011f0020 ECX: 090b071d EDX: 242c2c64 EBP: 008afc54 ESI: 00681ffe ESP: 008afc4c EDI: 011f1010 EFLAGS: 00010212 Frames: 77e30000+211d2 C:\ReactOS\system32\user32.dll 77e30000+21365 C:\ReactOS\system32\user32.dll 77e30000+20c56 C:\ReactOS\system32\user32.dll 400000+892c C:\ReactOS\user32_crosstest.exe 400000+8e73 C:\ReactOS\user32_crosstest.exe 400000+a3ab C:\ReactOS\user32_crosstest.exe 400000+b4ac8 C:\ReactOS\user32_crosstest.exe 400000+b4c56 C:\ReactOS\user32_crosstest.exe 400000+1247 C:\ReactOS\user32_crosstest.exe 400000+1298 C:\ReactOS\user32_crosstest.exe 7c700000+218e4 C:\ReactOS\system32\kernel32.dll (subsystems/win32/csrss/api/wapi.c:115) CSR: received hard error c0000144 (subsystems/win32/csrss/win32csr/dllmain.c:528) The instruction at "0x7c91e6ae" referenced memory at "0x00682000". The memory could not be "read". After patch: We have a thread overrun, these are already freed! pi -> 18808864 bi -> 6819854 We have a thread overrun, these are already freed! pi -> 18808864 bi -> 6819854 Than, get two exit strings at the command console. bi -> 6819854 (0x68100E) is the one and it is from MapViewOfFile. The difference from 0x682000 is 4082.... Well with in the normal page but why is 0x68100E the start address and not 0x681000? It could be just simply bad math being used in LoadBitmapImage. Wine does use the same code in user32 from gdi32 to handle bitmap and friends. Thanks, James

15 years, 9 months

Subpixel Rendering, ala sorta cleartype

by Steven Edwards

Hi rosdevs! This is an issue I've been working on for a while on the Wine side of things and now they have initial support for it. If any of you Win32k/GDI hackers are interested in making ReactOS look a bit better on LCDs please enable support in freetype and review the following Wine patch to get an idea of the requirements. Thanks http://source.winehq.org/git/wine.git/?a=commitdiff;h=028617b90ba586bdb3072… -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

15 years, 9 months

Trunk regression

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev