Ros-dev November 2010

ros-dev@reactos.org

31 participants
27 discussions

by Arko Provo Mukherjee

Dear All, Can you please kindly let me know which Virtualization tool I can use to run ReactOS. I am using Ubuntu currently and want to run ReactOS in top of that using a VM. Thanks a lot in advance! Warm regards Arko Provo Mukherjee

14 years, 10 months

winetest related regressions

by Timo Kreuzer

Just for the record: The changes are between r7324487 and r7281232. gdi32:palette +2 failures shell32:shlexec: crash user32:combo: +4 failures user32:cursoricon: -8 tests / +8 failures user32:edit: crash user32:monitor: not run user32:msg not run user32:win: -5743 tests winmm:mixer -192 tests

14 years, 11 months

Question regarding declaration of RTL_DRIVE_LETTER_CURDIR in include\ndk\rtltypes.h

by Sven Barth

Hello together! I'm currently poking around in the NDK headers very much and I noted a small inconsistency in the declaration of one type. The declaration is the following in include\ndk\rtltypes.h: ==== source begin ==== typedef struct RTL_DRIVE_LETTER_CURDIR { USHORT Flags; USHORT Length; ULONG TimeStamp; UNICODE_STRING DosPath; } RTL_DRIVE_LETTER_CURDIR, *PRTL_DRIVE_LETTER_CURDIR; ==== source end ==== Shouldn't it be "_RTL_DRIVE_LETTER_CURDIR" instead of "RTL_DRIVE_LETTER_CURDIR"? I don't know what influences this missing underscore has on compilation and such, cause I can read C without big problems and write a bit as well, but I don't understand every single bit a C compiler does ^^ Regards, Sven

14 years, 11 months

Re: [ros-dev] ReactOS official compatibility target and the new build system

by Samuel serapion

Doesn't windows use SxS to provide multiple versions of some dlls? I know its not for exacly the same purpose but perhaps coupled with some sort of app compat wizard we could really set hard version targets... but ofcourse it would mean building many dlls more than once On Nov 13, 2010 2:09 PM, "Colin Finck" <mail(a)colinfinck.de> wrote:

14 years, 11 months

ReactOS official compatibility target and the new build system

by Jérôme Gardou

Dear reactos developers. Once again, bringing reactos build to cmake arises questions. When this "port" has begun, it was decided that import libraries would be shipped with build environment, the now famous RosBE. This decision was made considering that : 1) functions exported by dlls do not change often. 2) Building an import library is a process that requires unneeded extra time. 3) 1 makes 2 unworthy. 4) If dll A imports function from dll B, it's not necessary to build B before A. 5) Solving 4 solves the problem of cross-dependency. As our target is win2k3 sp1 compatibility, a wise choice would be to choose import libraries that expose function only present on win2k3 sp1. The problem is that some wine dlls export functions that are from other windows versions, and, worse, use them. Let's see why this is a problem. - function A is a vista function from dll foo - function B is an XP function from dll bar - for some reasons, B implementation calls A. As you're clever developers ;-), you've seen that this would raise an error from the linker, as A is not present in our libfoo.a Hopefully, those cases are not too widespread, but they exist. Let's consider solutions that have arisen as of now : 1) Implement A as an inline function in headers, so anyone requiring it has it. 2) Linking bar.dll to some winefoo.dll, which forwards everything from foo.dll and exports the function A. 3) Add a "#if WIN32_WINNT > 0x502" before the guilty part of code, and "#else" with a win2k3 compliant implementation. 4) Oh dreams -> Ideally, convince wine to do it themself (./configure --wintarget=2k3sp1). 5) Change our target to win7, so we're ahead of wine. :-p 6) Do not change anything, and let our user mode libraries be a complete inconsistent anarchy. As 4 and 5 won't happen in a short time, let's consider 1, 2, 3 and 6: 1 is the best solution for easy winesyncs. We guard inline implementation by #ifndef BUILDING_FOO_DLL 2 would put a whole mess in system32 directory, but should be the most easy thing to do. 3 requires some extra work when syncing wine dlls. Though doing it often would reduce hassle. 6 isn't what I'd wish. What do you think? Your input is much appreciated. Best regards. The french speaking cmake team :-)

14 years, 11 months

[PREFIXES] in commit messages still useful?

by Colin Finck

Hi everyone, I'm wondering whether our [PREFIXES] in commit messages are still useful as of today? If I recall correctly, they were once added to autogenerate a changelog. I also remember that this dramatically failed when Ziliang created the 0.3.12 changelog and the full changelog needed to be redone from scratch, manually of course. Furthermore, I doubt that prefixes like "[SPRINTF]" (r49512) or faulty ones like "{ASM]" (r49413) can still be reasonably associated to a changelog category. After all, we don't even have a list of valid prefixes, so one has to first look at all used ones anyway. Of course, I don't want them to be dropped instantly tomorrow, but I'm interested in your opinions. I also don't yet know about the planned method for creating the 0.3.13 changelog, so I might be wrong on this. Cheers, Colin

14 years, 11 months

Networking

by Oleg Baikalow

Hi, I see you're busy discussing other stuff and my message went unnoticed :) I made a look to existing network branches, found many of them. LWIP is interesting. Alexey said the best way is to join your irc channel. I will try to occasionally join, but in your project, mailing list must be a primary point of discussion not irc channel. I think I start from making a simple, but robust tcpip driver (with help of numerously available source code of tcp/ip protocol implementations). Hopefully you could give me branch access, it's gonna be hard to develop it with patches. // Oleg Baikalow. P.S. I really like your "kernel coding style", quite rare to see that in opensource projects. Most of foss projects utilize linux-alike stlye, whic is harder to read and not that clean.

14 years, 11 months

Hook rewrite / regressions

by Aleksey Bragin

Hello, we have a serious regression in trunk which started 23rd of October with revision 49231 ("hook rewrite"). Considerable amount of time passed, automatic testing is not possible thus I'm afraid we are accumulating bugs. I think there is a need to revert 49231 + its dependencies in trunk to allow automated testing to work again and also fix regressions caused by this rewrite, and move this rewrite to a branch if possible. In future, it would be a good idea to: a. Discuss such serious rewrite merges beforehand (like Timo did with Yarotows). b. Try not to merge all rewrites simulteneously. E.g. I have to wait with heap rewrite merge (every rewrite contains a certain amount of bugs, by definition) even though it's fully ready. James - could you please share your opinion? The decision is yours, as you are the author of that commit. WBR, Aleksey Bragin.

14 years, 11 months

Exceptional exception handling

by Roel Messiant

Hey everyone, a few days ago, I started investigating a report in Bugzilla containing an application that raises an exception that goes unhandled, and the stack trace that gets printed is clearly corrupt. The report is the following: http://www.reactos.org/bugzilla/show_bug.cgi?id=5684 At first I thought the context wasn't being recorded properly, since both EBP and ESP are reported as being 0 at the time the exception was raised. However, there are applications for which we show a correct stack trace in case of an unhandled exception, so this most likely wasn't the case. My next thought was that we were somehow corrupting the context, but this wasn't the case either. The exception is also being dispatched nicely: exception handlers get the correct details. Lastly, the UnhandledExceptionFilter seemed to be passing the context on to the stack trace printing function without altering it, so the problem isn't there either. So where else could something be happening? That's right, inside one of the exception handler functions. Some of you may recognize the exception code (0xeedfade) in the bug report as a Delphi exception. I did too, so I fired up my copy of Delphi 6 and went digging in its exception handler functions. Every occurrence of UnhandledExceptionFilter in its exception handler functions showed the context wasn't being passed to it, but instead the registration frame was. This happens in a very predictive way however, so creating a patch (read: filthy hack) that detects this and fixes up the context record was easy. It is heavily tied to exactly this kind of defect, no general case. Running the application still triggers the exception of course, but now we get a reliable stack trace. A naive search in Bugzilla indicates at least the following reports are affected by this problem: Bug 3602, bug 3927, bug 5123 and bug 5684. I haven't tested them all, but the tell-tale signs are there. What does one do when encountering such a bug in compiler? Check if it still exists in the latest version and file a bug report of course. I got confirmation that the bug is present in the recently released Delphi XE with the help of Marco van de Voort of the FreePascal project (shameless plug, I know). A bug report has been filed with what I consider an extreme amount of detail and how to solve it in their product. Did I mention the report also contains a shameless plug to the ReactOS project? Today, to my astonishment, I found another report on their site which.. you guessed it.. mentions this problem. This report appears to have been made in 2007, so guessing when (newly compiled) Delphi applications will finally start calling UnhandledExceptionFilter correctly is an exercise I leave to the reader. Now to get to the question that some of you may already be asking, and is the purpose of this mail: Are we putting this hack into our codebase so we get a decent stack trace when an application messes up in the manner this mail is about, or not? Applications can mess this up in a lot of different ways, so it won't work on those. I warmly invite everyone to weigh in on this attempt of a discussion (which I hope will be productive), and hope people will see (again) that not everything that goes wrong in ReactOS is the fault of the OS. References for those interested in the nasty details: Bug report: http://qc.embarcadero.com/wc/qcmain.aspx?d=89377 Patch: Index: dll/win32/kernel32/except/except.c =================================================================== --- dll/win32/kernel32/except/except.c (revision 49448) +++ dll/win32/kernel32/except/except.c (working copy) @@ -218,6 +218,13 @@ PEXCEPTION_RECORD ExceptionRecord = ExceptionInfo->ExceptionRecord; PCONTEXT ContextRecord = ExceptionInfo->ContextRecord; + /* Attempt to hack around bad calls of UnhandledExceptionFilter */ + if ((ULONG_PTR) (ExceptionRecord->ExceptionAddress) != (ULONG_PTR) (ContextRecord->Eip)) + { + DPRINT1("Bogus context detected, using context record HACK!!\n"); + ContextRecord = (PCONTEXT) ExceptionInfo[1].ExceptionRecord; + } + /* Print a stack trace. */ DbgPrint("Unhandled exception\n"); DbgPrint("ExceptionCode: %8x\n", ExceptionRecord->ExceptionCode); @@ -415,11 +422,17 @@ if (dwExceptionCode == 0xeedface) { - DPRINT1("Delphi Exception at address: %p\n", ExceptionRecord.ExceptionInformation[0]); + DPRINT1("Delphi 2 Exception at address: %p\n", ExceptionRecord.ExceptionInformation[0]); DPRINT1("Exception-Object: %p\n", ExceptionRecord.ExceptionInformation[1]); DPRINT1("Exception text: %s\n", ExceptionRecord.ExceptionInformation[2]); } + if (dwExceptionCode == 0xeedfade) + { + DPRINT1("Delphi Exception at address: %p\n", ExceptionRecord.ExceptionInformation[0]); + DPRINT1("Exception-Object: %p\n", ExceptionRecord.ExceptionInformation[1]); + } + /* Trace the wine special error and show the modulename and functionname */ if (dwExceptionCode == 0x80000100 /*EXCEPTION_WINE_STUB*/) { WBR, Roel Messiant

14 years, 11 months

Re: [ros-dev] [ros-diffs] [fireball] 49465: [REGEDIT] Adam Kachwalla <geekdundee at gmail.

by Pierre Schweitzer

Hi, when commiting translation changes in a patch, please modify every language resources file. Think about our translators :). Best regards, P. Schweitzer

14 years, 11 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev November 2010