Wouldn't it be good to forward web-users to http://reactosde.re.funpic.de ?
or at least put a link for those wanting to go on with something?
Yours sincerely,
Jaix Bly
Hi.
I'm upgrading Subversion on svn.reactos.com to version 1.2.1
to correct some memory leaks in svnserve. Subversion 1.2.x
also brings us:
Faster access to old revisions. svn blame, svn checkout,
svn update, svn diff, svn merge will be faster.
Locking. If you have an 1.2.x client you can lock files and
directories. This is mostly useful for binaries so it's
possibly not something we will use much.
For faster access to old revisions, a "dump and load" of the
repository is needed so the repository will be unavailable
for a few hours today.
Casper
Hi,
It seems that the problem regarding Ged's RTL network card is related to
patch 15402:
http://svn.reactos.com/viewcvs?view=rev&rev=15402.
Is it possible that the card is incorrectly (or not in the same way we
are expecting) telling us its resource data? Or that somethign has been
overlooked? Ged has done a terrible deal of network testing for us but
he's been unable to work since his network card couldn't even ping
anymore. I've helped him find the regression and I hope someone more
experienced in PnP can help him out... at least we know what patch did it.
Best regards,
Alex Ionescu
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
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
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
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