- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [fireball] 50000: [HEAP] - Time has come to get rid of a slightly modified implementation of WINE's heap, which is a hack based on Windows 95's heap implementation, itself a hack of DOS memory mana...

by Ged Murphy

A worthy commit for r50000. You've been waiting for this revision, haven't you .... haha. Ged -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of fireball(a)svn.reactos.org Sent: 10 December 2010 09:33 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [fireball] 50000: [HEAP] - Time has come to get rid of a slightly modified implementation of WINE's heap, which is a hack based on Windows 95's heap implementation, itself a hack of DOS memory mana... Author: fireball Date: Fri Dec 10 09:33:20 2010 New Revision: 50000 URL: http://svn.reactos.org/svn/reactos?rev=50000&view=rev Log: [HEAP] - Time has come to get rid of a slightly modified implementation of WINE's heap, which is a hack based on Windows 95's heap implementation, itself a hack of DOS memory management. It supported 3 out of the 18 possible NT Heap Flags, did not support custom allocation/deallocation routines, and was about 50-80x slower with fragmentation rates up to 500x higher when compared to NT's LFH (WINE is lucky because the advanced NT Heap features are used in kernel-mode usually, not in user-mode, and they are crossing their fingers for this being the same). Several high-end SQL/Database applications would significantly benefit from custom heap features provided by NT. Not to say about removing crappy support for a custom Commit routine and crappy support for User-defined flags and the User-defined value. - So, the glorious moment for a new heap manager, which is (to remind you) a totally new heap manager, resembling real NT heap manager, based on data structures similar to Windows 2003 and Vista+'s heap structures, supporting advanced heap flags (e.g. useful for debugging), having substantially lower fragmentation rates (and thus speed and reliability), having native support for user-defined flags and user-defined values, also native support for a custom commit routine, which is very important for trunk's win32 subsystem. It also reserves, commits, decommits and frees memory on the fly, unlike existing heap manager which prefers to reserve and commit as much as possible, and doesn't decommit when it's no longer necessary. Not to say about support for per process heaps, with a proper lock, and a further support for a special so-called debug heap allocator (to be implemented in heapdbg.c) which will be useful for finding heap corruptions. Yeah, I'm not a fun person :D Added: trunk/reactos/lib/rtl/heap.c - copied unchanged from r49999, trunk/reactos/lib/rtl/heap_rewrite.c Removed: trunk/reactos/lib/rtl/heap_rewrite.c [This mail would be too long, it was shortened to contain the URLs only.] Removed: trunk/reactos/lib/rtl/heap_rewrite.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/heap_rewrite.c?rev…

14 years, 9 months

4
3
0 0

Re: [ros-dev] Ros-dev Digest, Vol 76, Issue 1

by Manikandan

HI Can you tell me the files that are to be installed at time of booting the system with reactos?. With regards Mani

14 years, 9 months

2
1
0 0

Re: [ros-dev] [ros-diffs] [greatlrd] 49912: all code are in ReactOS trunk for ReactX delete the old branch and prepare create new one Most of the code will be focus on dxg.sys and few part of gdi32.dll in the new branch of ...

by Ged Murphy

greatlrd(a)svn.reactos.org wrote: > Sent: 03 December 2010 09:20 > To: ros-diffs(a)reactos.org > Subject: [ros-diffs] [greatlrd] 49912: all code are in > ReactOS trunk for ReactX delete the old branch and prepare > create new one Most of the code will be focus on dxg.sys and > few part of gdi32.dll in the new branch of ... Hells bells, it's gratelood! Good to see you back mate. Ged.

14 years, 9 months

1
0
0 0

Testbot

by Pierre Schweitzer

Hi, anyone (ie Colin or Christoph?) knows what's wrong with testbot? Since r49761 it can't reach 2nd stage & more. This revision has been reverted in r49767 but testbot keeps being broken. Any clue? Regards, P. Schweitzer

14 years, 9 months

2
1
0 0

Re: [ros-dev] Ros-dev Digest, Vol 75, Issue 27

by Manikandan

> > I am new to reactos and i want to study it in detail. For that I wish to > construct it manually. So can u tell me the important files needed to boot > the reactos. Thanking you.

14 years, 9 months

3
2
0 0

Unable to build ReactOS anymore

by Ros Arm

Hello, Why everyone else had been complaining on how we should revert changes that expose compiler bugs, I, on the other hand, have not even been able to build ReactOS anymore starting with recent revisions (probably related to C++ changes). Anyone want to fix this, please? [PCH] obj-i386/base/shell/explorer/.gch_explorer/precomp.h.gch In file included from /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/localefwd.h:42, from /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/string:45, from base/shell/explorer/utility/utility.h:58, from base/shell/explorer/precomp.h:33: /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/mingw32/bits/c++locale.h: In function 'int std::__convert_from_v(int* const&, char*, int, const char*, ...)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/mingw32/bits/c++locale.h:74: error: expected primary-expression before ',' token In file included from /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/string:46, from base/shell/explorer/utility/utility.h:58, from base/shell/explorer/precomp.h:33: /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h: In function 'void std::__ostream_write(std::basic_ostream<_CharT, _Traits>&, const _CharT*, std::streamsize)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:48: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:50: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h: In function 'void std::__ostream_fill(std::basic_ostream<_CharT, _Traits>&, std::streamsize)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:60: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:63: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:66: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h: In function 'std::basic_ostream<_CharT, _Traits>& std::__ostream_insert(std::basic_ostream<_CharT, _Traits>&, const _CharT*, std::streamsize)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:85: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:88: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:92: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:93: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:94: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:95: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:96: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:99: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:100: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:104: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream_insert.h:108: error: expected primary-expression before '.' token In file included from /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/iostream:40, from base/shell/explorer/utility/utility.h:59, from base/shell/explorer/precomp.h:33: /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, _CharT)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:447: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, char)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:452: error: expected primary-expression before '<<' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:452: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char, _Traits>&, char)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:458: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char, _Traits>&, signed char)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:464: error: expected primary-expression before '<<' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char, _Traits>&, unsigned char)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:469: error: expected primary-expression before '<<' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const _CharT*)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:491: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:493: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char, _Traits>&, const char*)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:508: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:510: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char, _Traits>&, const signed char*)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:519: error: expected primary-expression before '<<' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char, _Traits>&, const unsigned char*)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:524: error: expected primary-expression before '<<' token In file included from /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:565, from /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/iostream:40, from base/shell/explorer/utility/utility.h:59, from base/shell/explorer/precomp.h:33: /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream.tcc: In function 'std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const char*)': /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream.tcc:324: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream.tcc:342: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream.tcc:343: error: expected primary-expression before ',' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream.tcc:347: error: expected primary-expression before '.' token /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/bits/ostream.tcc:351: error: expected primary-expression before '.' token In file included from /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/iostream:40, from base/shell/explorer/utility/utility.h:59, from base/shell/explorer/precomp.h:33: /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream: In function 'std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char, _Traits>&, const char*) [with _Traits = std::char_traits<char>]': base/shell/explorer/utility/xmlstorage.h:2923: instantiated from here /usr/local/RosBE/i386/lib/gcc/mingw32/4.4.2/include/c++/ostream:512: error: return-statement with no value, in function returning 'std::basic_ostream<char, std::char_traits<char> >&' make: *** [obj-i386/base/shell/explorer/.gch_explorer/precomp.h.gch] Error 1 -r

14 years, 9 months

2
1
0 0

Video of ReactOS Booting on ARM

by Ros Arm

Hello, As some have asked, http://www.youtube.com/watch?v=RFNuY2OFRjU&hd=1 Cheers! -r

14 years, 9 months

6
7
0 0

Comments regarding r49691

by Pierre Schweitzer

Hi, most of the justifications for r49691 have been included in the commit message. But here are needed addings. Olaf made buildbot rebuild r49662 and retest it. Testbot manages to pass 3rd stage and to run tests. Then, Olaf retried with r49665, and it failed the same way it was failing earlier. So, we are reverting to "last good known state", aka r49662. Only two issues have been seen there: - one with MM: (ARM³::PAGFAULT:751) PAGE TABLES FAULTED IN! You can find full log here: http://download.myreactos.com/Amine/49662%20testbot%20ouptput-stdio.7z (thanks to Sylvain) - One with NPFS. Aleksey and Eric are already working on it. You can easily find it on testbot output. Other issues may also be found as many commits were done while testbot was down. Please don't start a drama on that revision. Whatever you may think about it, we cannot stay with a broken testbot forever and people keeping on committing. Taking a decision trying to sort out a mess is being professional. All the help everyone will be able to give will be appreciated! Thanks. P. Schweitzer PS: For ReactOS testbot raw results, don't forget: http://build.reactos.org:8010/ You'll find the tests ran today.

14 years, 10 months

1
2
0 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 49662: [NTOSKRNL] [HAL] Disable INIT_FUNCTION to s

by Pierre Schweitzer

Hi, finally this commit won't be reverted (unless someone explicitly asks for it) as it brings testman back and shows quite important bugs. Feel free to find a nice bugfix instead. WBR, P. Schweitzer

14 years, 10 months

4
9
0 0

Official buildbot

by Olaf Siejka

Hiya It looks like buildbot has crashed or been shut down. I restarted the master but have no access to slaves. It will at least gather the build requests, but the missing ones since last 6 hours need to be forced manually. Christoph, could you take a look at the slaves?? Regards

14 years, 10 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [ekohl] 49646: [NPFS] - Rename DEVICE_EXTENSION to NPFS_VCB. - Add a type variable to distinguish FCBs and CCBs for device, directory or pipe. - Attach an FCB to the VCB that represents the root di...

by Aleksey Bragin

Great work, one more driver incompatibility away! WBR, Aleksey Bragin. On Nov 20, 2010, at 1:42 AM, ekohl(a)svn.reactos.org wrote: > Author: ekohl > Date: Fri Nov 19 22:42:53 2010 > New Revision: 49646 > > URL: http://svn.reactos.org/svn/reactos?rev=49646&view=rev > Log: > [NPFS] > - Rename DEVICE_EXTENSION to NPFS_VCB. > - Add a type variable to distinguish FCBs and CCBs for device, > directory or pipe. > - Attach an FCB to the VCB that represents the root directory of > the file system and implement an open routine for the root directory. > - Make NpfsWaitPipe work when it is called for the root directory. > > [KERNEL32] > - Remove the old version of WaitNamedPipeW. > > This patch fixes the broken wait pipe code. It was written and > tested on r49458 because later revisions do not work for me.

14 years, 10 months

1
0
0 0

Something for the holidays?

by Ros Arm

http://img824.imageshack.us/img824/734/stuffy.png -r

14 years, 10 months

6
8
0 0

Virtualization tool to run ReactOS

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

4
4
0 0

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, 10 months

2
3
0 0

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, 10 months

5
8
0 0

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, 10 months

3
2
0 0

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, 10 months

6
18
0 0

[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, 10 months

5
4
0 0

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, 10 months

17
28
0 0

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, 10 months

4
10
0 0

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, 10 months

2
4
0 0

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, 10 months

4
5
0 0

Re: [ros-dev] explorer_new

by Ged Murphy

Exactly. The current explorer is self contained and incorrect according to true win32 shell architecture. Our shell libraries aren’t complete enough to support the new explorer. Andrew Hill was working on these libraries along with a basic ATL implementation some time ago. I haven’t heard from him for a while now though. Ged. From: Adam Kachwalla [mailto:geekdundee@gmail.com] Sent: 03 November 2010 08:51 To: Ged Murphy Subject: Re: [ros-dev] explorer_new Interesting... so I guess the old explorer.exe implemented that from scratch - I guess the one in shell32 is incomplete then right? On Wed, 03 Nov 2010 19:50:18 +1100, Ged Murphy <gedmurphy(a)gmail.com> wrote: It’s implemented in shell32 as an undocumented COM object. From: Adam Kachwalla [mailto:geekdundee@gmail.com] Sent: 03 November 2010 08:34 To: Ged Murphy Subject: Re: [ros-dev] explorer_new It is part of the shell though isn't it? If start menu isn't part of explorer then what is it part of? On Wed, 03 Nov 2010 19:32:53 +1100, Ged Murphy <gedmurphy(a)gmail.com> wrote: That’s because the start menu isn’t part of explorer From: Adam Kachwalla [mailto:geekdundee@gmail.com] Sent: 03 November 2010 08:28 To: 'ReactOS Development List'; Ged Murphy Subject: Re: [ros-dev] explorer_new Although it seems completely non-functional in the latest trunk builds. Start menu doesn't work, etc. On Wed, 03 Nov 2010 19:23:29 +1100, Ged Murphy <gedmurphy(a)gmail.com> wrote: It’s relatively complete, it’s the support libraries which are incomplete. The only people with then necessary COM and shell skills (which is only really 2 of the ros devs) are either busy with other things or on sabbatical. Ged. From: ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Adam Kachwalla Sent: 03 November 2010 01:19 To: ReactOS Development List Subject: [ros-dev] explorer_new Can anybody tell me what explorer_new is meant to be there for? I understand people used to be working on it before, but it seems abandoned. -- Give a man a fish and he will eat for a day. Teach a man to fish and he will eat for a lifetime. Give a man religion and he will die praying for a fish. -- Give a man a fish and he will eat for a day. Teach a man to fish and he will eat for a lifetime. Give a man religion and he will die praying for a fish. -- Give a man a fish and he will eat for a day. Teach a man to fish and he will eat for a lifetime. Give a man religion and he will die praying for a fish.

14 years, 10 months

2
2
0 0

explorer_new

by Adam Kachwalla

Can anybody tell me what explorer_new is meant to be there for? I understand people used to be working on it before, but it seems abandoned.

14 years, 10 months

4
5
0 0

Keyboard device question

by Fan Zhang

Hi guys, I'm reading win32k.sys right now. I found KeyboardThreadMain thread only use KeyboardClass0 device. I want to know how to communicate KeyboardClass1,KeyboardClass2, and so on? Fan Zhang

14 years, 10 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev