Ros-dev

ros-dev@reactos.org

5790 discussions

Re: [ros-diffs] [ion] 16730: - Final ROSRTL removal patch. The next patch will remove the actual library and code.
by Hartmut Birr 28 Jul '05

28 Jul '05

ion(a)svn.reactos.com wrote: >- Final ROSRTL removal patch. The next patch will remove the actual library and code. >- Changes: > - CreateProcess > * Cleanup creation of the initial thread using new utility functions and remove rosrtl > * Almost entirely rewrote the function to support features such as: > - SxS (locally only, patch will follow), > - SFP (SAFER) (locally only, patch will follow), > - DllPaths (locally only, patch will follow), > - Proper process environment/paramter block creation > - Proper console handle management (needs more work in kernel32/csr), > - Tokens/CreateProcessAsUser (locally only, patch will follow), > - Simpler code for path lookup, and more robust. > - Support for "auto-correction" (see Raymond Chen's blog) > - 16-bit/NE detection > - A variety of creation flags are now properly supported > - Added support for an undocumented-yet-known (see comment) shell flag > - Alert for flags we don't support yet > - Catch invalid flag combinations and other caller errors > - Improve and correct path searcing to use documented behaviours > - Created a multitude of helper functions to make the code easier to read > and allow them to be used for other apis as time goes on. > > - BaseProcessStartup > * Call NtSetThreadInformation to let the Kernel know of the Thread's Start Address. > * Correct prototype of Thread Startup function for this case. > >This fixes MANY things, some of which may not be evident, and possibly creates regressions which I have not yet seen but will try to correct. Some of these may be caused by the fact that I've seen code send CreateProcessW incorrect flags. Some things of note: DO NOT send partial names as "lpApplicationName". It's not supposed to work unless you're in the same current directory. Also, do NOT send CREATE_UNICODE_ENVIRONMENT if you don't have a unicode environement, and vice-versa. I've seen lots of code doing mistakes related to this. I hope you appreciate this patch and won't all jump on me for possbile regressions :(. > >Modified: trunk/reactos/lib/kernel32/process/create.c >Modified: trunk/reactos/lib/kernel32/thread/i386/thread.S >Modified: trunk/reactos/lib/kernel32/thread/thread.c >Modified: trunk/reactos/ntoskrnl/mm/process.c > > > ------------------------------------------------------------------------ Hi, your rewrite of CreateProcess is broken. Before you can inform csrss about the process creation, you have to gather all informations about handles and creation options. After your commit, each console application creates its own console window and the redirection of standard handles is broken. It seems also that the inheritance of msvcrt file id's is broken. This stops compiling ros on ros. - Hartmut

3 2

Crash by starting OOo1.4 setup.exe (r16740)
by reactos 28 Jul '05

28 Jul '05

OOo1.4 Setup is crashing ROS, here comes a crashreport ROS r16740 Yours sincerely, Jaix Bly

3 2

Re: [ros-svn] [ion] 16728: - Don't try to get the length of a possibly empty string. This fixes many menu applications (such as WinRAR). However I'm now getting a bug due to a double-free. It seems a GDI Object is being freed twice. Can anyone check this out please?
by Alex Ionescu 27 Jul '05

27 Jul '05

ion(a)svn.reactos.com wrote: > - Don't try to get the length of a possibly empty string. This fixes many menu applications (such as WinRAR). However I'm now getting a bug due to a double-free. It seems a GDI Object is being freed twice. Can anyone check this out please? > > > With the combination of this patch + Hartmut's patch + DBG = 0 build (and/or disabling RZ detection), Winrar runs fine again. However, pressing OK in the dialog bug causes a crash in RtlFreeUnicodeString->RtlpFreeMemory->ExFreePool. It seems the buffer is invalid. So it looks like two things have to be fixed for Winrar and other apps to work fine (Windows Commander does work now): 1) Stop the GDI Object from being freed twice. This will fix the first bugcheck and allow Winrar to work in DBG = 1 with RZ enabled. Disabling RZ is only a hack and shouldn't be used a solution. The stack trace ships the double-free routine pretty well, but I'm not well versed in win32k to fix this. 2) Find out why we are RtlFreeUnicodestring-ing what seems to be an invalid pointer. I think if we can fix these two issues we'll have many more apps working again! I've tested Winrar 3.50 b7, btw. Best regards, Alex Ionescu

3 3

Re: [ros-diffs] [ion] 16804: - Include ctype.h by default.
by Hartmut Birr 27 Jul '05

27 Jul '05

ion(a)svn.reactos.com wrote: >- Include ctype.h by default. > >Modified: trunk/reactos/w32api/include/winnt.h > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/w32api/include/winnt.h* > >--- trunk/reactos/w32api/include/winnt.h 2005-07-27 16:34:14 UTC (rev 16803) >+++ trunk/reactos/w32api/include/winnt.h 2005-07-27 16:55:40 UTC (rev 16804) >@@ -34,6 +34,7 @@ > > extern "C" { > #endif > > > >+#include <ctype.h> > > > #include <winerror.h> > > #ifndef RC_INVOKED > > Hi, this changing is wrong (and some other with ctype.h). You can't include ctype.h from mingw for optimized builds (DBG = 0), because ctype.h from mingw needs to import msvcrt.dll. - Hartmut

2 1

Blockers...
by Alex Ionescu 27 Jul '05

27 Jul '05

Hi, Here is a current update on the 0.2.7 blockers...if you can help, please DO! BUG: - Green icon in run dialog REGRESSION IDENTIFIED: Yes. By WaxDragon. Regression due to BUILD. CAUSE: Incorrect icon was added to resource file. FIXED: Yes. Fix needs to be merged into 0.2.7 branch. ------------------- BUG: - Common Dialog Control Broken for File/Save. REGRESSION IDENTIFIED: Yes. By WaxDragon. Regression due to 15669. CAUSE: Building shell32 as ANSI causes this problem. Building it as UNICODE however breaks the My computer dialog. Shell32 should be built as Unicode, and the My computer dialog should appear when double-clicked. So this bug needs to be fixed. ---------------------- BUG: - If you use the arrow keys in the explorer start menu to expand an entry, you cannot use them anymore to go up and down. No further information has been researched yet. Martin, explorer is your baby, and I'm sure is an easy fix...it doesnt' happen with the right-click context menu on the desktop, so maybe this is localized to some bug in your start menu code? --------------------- BUG: - If you right-click on the desktop to show the context menu, then right-click again, then left-click (or other similar combinations), your next right-click is not registered anymore. No further information is available, although I belive hpoussin said the problem is above win32k. I haven't heard from tinus in a long time, but i8042prt might be where this problem resides. ------------------- BUG: - Several applications have regressed due to "memory corruption" and a bugcheck related to NtGdiRealizePallette. More information is on the Bugzilla DB, but it's down atm. I have heard reports that the error always happened before, but wasn't seen because red zone pool protection was disabled. In any case, it breaks a large number of apps. -------------------- BUG: - AllocConsole failure in 1st-stage setup on Dell Laptops (and maybe others). REGRESSION IDENTIFIED: Yes. By BrandonTurner. A regression range has been identified and 3 key builds are being tested to find the actual regression. Best Regards, Alex Ionescu

21 36

Re: [ros-svn] [gdalsnes] 16793: my 1st
by Alex Ionescu 27 Jul '05

27 Jul '05

gdalsnes(a)svn.reactos.com wrote: >my 1st > > >Added files: >branches/hardons1stbranch/ > >Updated files: >branches/hardons1stbranch/kapi.h >branches/hardons1stbranch/ntuser.h > >Deleted files: >branches/hardons1stbranch/debug.h >branches/hardons1stbranch/debug1.h > > > Hi, I thought our pre-established branching rules recommend using an actual meaningful branch name? Not a generic user branch, but a feature branch. Best regards, Alex Ionescu

1 0

RE: [ros-svn] [gdalsnes] 16793: my 1st
by Casper Hornstrup 27 Jul '05

27 Jul '05

Can't you rename it to something that reflects its purpose? Casper > -----Original Message----- > From: ros-svn-bounces(a)reactos.com [mailto:ros-svn-bounces@reactos.com] On Behalf Of > gdalsnes(a)svn.reactos.com > Sent: 27. juli 2005 13:07 > To: ros-svn(a)reactos.com > Subject: [ros-svn] [gdalsnes] 16793: my 1st > > my 1st > > > Added files: > branches/hardons1stbranch/ > > Updated files: > branches/hardons1stbranch/kapi.h > branches/hardons1stbranch/ntuser.h > > Deleted files: > branches/hardons1stbranch/debug.h > branches/hardons1stbranch/debug1.h > > _______________________________________________ > Ros-svn mailing list > Ros-svn(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-svn

2 1

Re: [ros-svn] [ion] 16727: - Message Queue Fix, resolves a number of application regressions (Total Commander works again, for example). Patch by Hartmut Birr. To be commited into 0.2.7 after more testing.
by Hartmut Birr 26 Jul '05

26 Jul '05

ion(a)svn.reactos.com wrote: > - Message Queue Fix, resolves a number of application regressions (Total Commander works again, for example). Patch by Hartmut Birr. To be commited into 0.2.7 after more testing. > > >Updated files: >trunk/reactos/subsys/win32k/ntuser/window.c > > > Hi, this fix wasn't for commiting, because it doesn't solve the real problem. The destroying of the message queues is intitiated by calling Win32kThreadCallback which calls MsqDestroyMessageQueue. After this call, it shouldn't exist anymore a window for this thread. - Hartmut

2 1

Re: [ros-svn] [hbirr] 16758: Lock the handle table if we trying to get a pointer from a handle.
by Thomas Weidenmueller 26 Jul '05

26 Jul '05

hbirr(a)svn.reactos.com wrote: > Lock the handle table if we trying to get a pointer from a handle. These changes are incorrect. Please revert them. Actually, a handle lookup requires _no_ locks at all. If you don't believe me, read up Windows Internals (4th Edition). The algorithms to allocate subtables are implemented in such a way that it is impossible to page fault on a lookup. However, it is not allowed to do a lookup in a table unless attached to the process that owns it (except it is a global handle table). Best Regards, Thomas

1 0

Mozilla Embedded locks in ROS r16740
by reactos 26 Jul '05

26 Jul '05

Hello all devs, I am running Mozilla-Embedded (same as BartPE) because I can not get the Mozilla Controll to work, usually this is alright, but since some weeks ago Moz-Embedded locks the computer after the shell says "You're embedded man..." and before the mainwindow starts. It usually took a long time for the mainwindow to start, but it used to work, and I think it takes aproximately the same time for the mouse (and the rest of the system) to lock in r16740. I do not get any error-messages, someone with debugging skills has to look at this. Mozilla embedded can be found here: http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6a/mozilla… Yours sincerely, Jaix Bly

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev