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
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
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
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:
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 :-)
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
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.
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.
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
Hi,
when commiting translation changes in a patch, please modify every language resources file.
Think about our translators :).
Best regards,
P. Schweitzer