- Ros-dev - ReactOS.org

scared! freedce-win32 in a cvs repository near you
by Luke Kenneth Casson Leighton 19 Sep '05

19 Sep '05

right. 48 hours later, i've got a first version of freedce-win32 to try out, which i'm actually a bit frightened of running. just in case it works :) thank goodness for pthreads-win32, otherwise i'd be up small creek. major things todo: in ipnaf.c (actually ipnaf_linux.c or even better ipnaf_win32.c) it's necessary to write an IP-interface-enumeration function. this function presumably will call GetIpAddrTable and go over all the addresses including netmasks and broadcast addresses returning information that the rpc runtime can then "listen" on - one by one. no, freedce doesn't go listening on 0.0.0.0 it binds to all "towers" whatever they're called. because i've commented this code out (stubbed) i am not expecting freedce-win32 to work straight off. once this is working, putting it in place of rpcrt4 should be relatively straightforward (and mostly very very mind numbingly boring) - a matter of "back-converting" and following the lead of dceport.h - microsoft's "wrapper" header file that allows application developers to port DCE/RPC applications to MSRPC. i say "lead" because it's woefully inadequate, representing about 10% of the functions and structs that actually need "converting", because dceport.h contains the "publicly accessible" functions. once _that's_ done, then there will be two remaining tasks: 1) check that pthreads-win32 works under wine (!) and if so, job done, otherwise it's _yet_ another emulation layer to write, but at least the source code of pthreads-win32 represents a damn good starting point 2) mash freedce's typelib output to be compatible with MSRPC binaries. this latter is no small task (but at least it could be considered). the data structures have been _totally_ mashed, by microsoft. gotta run. later. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

Re: [ros-bugs] [Bug 751] Putty - Ntoskrnl bugcheck when sending login/Password to FTP server
by WaxDragon 19 Sep '05

19 Sep '05

GvG and I have both seen this multiple char behaviour. I think I still need to file a bug on it. ;0/ On 9/18/05, ReactOS.Bugzilla(a)reactos.com <ReactOS.Bugzilla(a)reactos.com> wrote: > http://reactos.com/bugzilla/show_bug.cgi?id=751 > > > > > > ------- Additional Comments From gerard.gatineau(a)laposte.net 2005-18-09 19:33 ------- > With svn 17912 , There is no bugcheck when Putty is configured for protocol = > SSH and port 22 to connect to my FTP server : > > Reception of " login as " > Type login name (abcd..) > Display of login name in putty window is incorrect ( aabbccdd..) > > Debug messages are output for each character typed > so->so_state 102 > (lib\imm32\imm.c:471) (000201d0): stub > (lib\imm32\imm.c:940) (00000000, 005ac9e4): stub > (lib\imm32\imm.c:818) (000201d0, 00000000): stub > (lib\imm32\imm.c:471) (000201d0): stub > (lib\imm32\imm.c:940) (00000000, 005aca14): stub > (lib\imm32\imm.c:818) (000201d0, 00000000): stub > (lib\imm32\imm.c:471) (000201d0): stub > (lib\imm32\imm.c:940) (00000000, 005aca14): stub > (lib\imm32\imm.c:818) (000201d0, 00000000): stub > so->so_state 102 > > Note : Not sure if this test makes sense with ftp server > > -- > Configure bugmail: http://reactos.com/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > _______________________________________________ > Ros-bugs mailing list > Ros-bugs(a)reactos.com > http://reactos.com/mailman/listinfo/ros-bugs > -- <arty> don't question it ... it's clearly an optimization

2 1

How far is the user(login) system implemented?
by Jasper Huzen 18 Sep '05

18 Sep '05

Hi, We are a group of students and we are interested in writing the user(login) system into ReactOS (we have he project with the subject 'Security' and we may choose a security project) Can anyone tell me how far the user system (userlogin and security of users) implemented????? Jasper MSN: jhuzen(a)hotmail.com

1 0

freedce-win32 - winsock joy
by Luke Kenneth Casson Leighton 18 Sep '05

18 Sep '05

progress being made. am about 10-15% the way through a compile, having previously got dcethreads to use pthread-win32 by judicious ripping out of large amounts of code. fortunately, elrond has already win32'd tng, so there is stacks of code in tng's lib/util_sock.c to rip off :) -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

Re: [ros-svn] [hbirr] 17910: Don't check the share access for directories.
by KJKHyperion 18 Sep '05

18 Sep '05

hbirr(a)svn.reactos.com wrote: >Don't check the share access for directories. > are you sure this is right? I quite remember share access being enforced on directories

2 3

Re: [ros-diffs] [hbirr] 17912: The share disposition isn't necessary for FILE_READ_ATTRIBUTES.
by Gunnar Dalsnes 18 Sep '05

18 Sep '05

Is this correct? I can't see how... Even GENERIC_READ imply FILE_READ_ATTRIBUTES and using your "share disposition isn't necessary for FILE_READ_ATTRIBUTES rule" this means file sharing isnt needed for GENERIC_READ either... hbirr(a)svn.reactos.com wrote: > The share disposition isn't necessary for FILE_READ_ATTRIBUTES. > > Modified: trunk/reactos/lib/kernel32/file/file.c > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/lib/kernel32/file/file.c* > > --- trunk/reactos/lib/kernel32/file/file.c 2005-09-18 13:36:29 UTC (rev 17911) > +++ trunk/reactos/lib/kernel32/file/file.c 2005-09-18 13:46:37 UTC (rev 17912) > @@ -873,7 +873,7 @@ > > SYNCHRONIZE | FILE_READ_ATTRIBUTES, > &ObjectAttributes, > &IoStatusBlock, > > - FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE, > > + 0, > > FILE_SYNCHRONOUS_IO_NONALERT); > RtlFreeUnicodeString (&FileName); > if (!NT_SUCCESS (Status)) >

2 2

Re: [ros-diffs] [greatlrd] 17909: give GetFileAttributesExW more NtOpenFile right to prevent reactos crash if u using CreateFile then GetFileAttributesExW. It also fix a bug for me for livecd it booting on first try now in vmware. instead second or more booting try.
by Gunnar Dalsnes 18 Sep '05

18 Sep '05

greatlrd(a)svn.reactos.com wrote: > give GetFileAttributesExW more NtOpenFile right to prevent reactos crash if u using CreateFile then GetFileAttributesExW. It also fix a bug for me for livecd it booting on first try now in vmware. instead second or more booting try. "crash if using CreateFile then GetFileAttributesExW" ??? What?? It looks like you are working around the real bug by using a _very_ dirty workaround. > > Modified: trunk/reactos/lib/kernel32/file/file.c > > - SYNCHRONIZE | FILE_READ_ATTRIBUTES, > > + SYNCHRONIZE | GENERIC_ALL, > FILE_READ_ATTRIBUTES access is surely sufficient for reading a files attributes...

1 0

found it! the "dce porting" header file
by Luke Kenneth Casson Leighton 18 Sep '05

18 Sep '05

http://examples.oreilly.de/english_examples/dce/dce_nt/dceport.h.aug95 o joy o joy. also, i found _this_!!! http://sourceware.org/pthreads-win32/ which is an implementation of pthreads on win32. _also_ i found - was reminded - by judicious searching on google, that of course entegrity.com have "PC-DCE" which is of course a _commercial_ product that has done exactly the work required: making dce (1.1? 1.2.2?) compile on Win32. including exceptions, dealing with mapping the names, blah blahhh. now. anyone got any brainy ideas on how to reverse dceport.h - in particular the thingy. wotsit. TRY/FINALLY/CATCH stuff? what i'm going to try to do is take a shot at simply compiling dcethreads - on win32. if that _works_ (the tests pass) it'll be great - it will prove two things: 1) that pthreads-win32 works 2) that the dce exception handling will fly, on win32, and _that_ means pretty much zero (urk! let's hope!) work. for now. my main goal: "GetItWorking(tm)". i couldn't care less about binary compatibility for now: i want "services" - i want srvsvcd, i want winregd, i want lsarpcd, i want samrd - all compiled, all working, using TCP/IP. i can then work on rewriting freedce's ntlmsspauth.so to be a DLL (starting off as my favourite - a stub with username and password of "test"). i can then work on writing an "ncalrpc" plugin transport (which is very straightforward: a matter of filling in about 25 functions in a vector table). and also on a ncacn_np plugin transport. "working" means that other people will then be able to focus on issues like binary compatibility. guys (wine team) i have to say this. you were utterly insane to not use freedce as your starting point - and i am still bewildered by you not even looking at its source code (which is topologically identical in almost all areas, to what you've created) or the opengroup's documentation. i say that with the greatest of respect for what you've achieved without freedce. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

8 11

compiling botched version of dcethreads exception using pthread-win32 - WORKS!
by Luke Kenneth Casson Leighton 18 Sep '05

18 Sep '05

okay, it's not time to get totally excited yet, but i have successfully compiled - and run, and confirmed as working on ros - some of the test programs from dcethreads (http://sf.net/projects/freedce) when cross-compiled with mingw32 and linked with pthreads-win32. this is _very_ significant because it means that there is a good chance of replicating entegrity's work - PC-DCE - with zero modifications to the freedce source code. i've cut out entirely the dcethreads "emulation" stuff, which means that dcethreads posix draft 4 compliance - including the ability to pass on thread cancellation across an RPC client/server app boundary, and including the ability to pass on signals across an RPC client/server app boundary - are completely out the window... ... but i don't care. so. the bits "remaining" in my hacked-together-version of dcethreads is _just_ the exception handling - exc_handling.c and exc_handling.h pretty much. that means that the DCE "TRY", "RAISE", "CATCH" and "EXCEPT" macros are all there. it's early days, but this is good news. now. here's what i don't want to hear from anyone: q) "why in hell's name are you doing this? why can't you just remove all references to posix threads and all references to DCE/RPC exception handling?" a) lkcl@highfield:~/sf/freedce/freedce$ find . | xargs grep pthread | wc 770 3965 64010 lkcl@highfield:~/sf/freedce/freedce$ find . -name "*.[ch]" | xargs grep ENDTRY | wc 105 248 4490 lkcl@highfield:~/sf/freedce/freedce$ find . -name "*.[ch]" | xargs grep RAISE | wc 202 731 12799 lkcl@highfield:~/sf/freedce/freedce$ find . -name "*.[ch]" | xargs grep CATCH | wc 217 685 12392 in short: modifying several thousand lines of code, by hand, is something that microsoft can happily pay some donut code-dunker to do (and did, probably back in 1990-1993) but i sure as hell ain't doing it for a proof-of-concept bit of work. q) "why are you doing this and doing it to _us_? go away!!" a) you are inflicting much pain upon yourselves, even though you probably don't know it. don't like what i'm doing, don't like what i have to say? tough - get over it: i don't have time or money to waste to stroke egos. i'll give you what time i can and what facts i can and also i will present you with an opinion: if you don't like that opinion or the way it's presented, that is your choice. live with it, deal with it or ignore it - i'll pretend i don't care which. i give you information, present you with choices: where you go from there - as neo says as the end of matrix 1.... l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

2 1

Trunk Freeze
by WaxDragon 17 Sep '05

17 Sep '05

It's only been two weeks since I sent out the August State of the Repository, but the tree has already had 271 revisions. There have been several large commits, and trunk has had several build breakages, and instability in general. Just today we had three commits reversing and unreversing some of Alex's changes. I'm calling for a trunk freeze until several issues have been addressed. * The release build is broken. So far the string library and the usb code have been fixed. I was working with Alex on a break in the exception handling when this topic came up. * There seems to be a mysterious hang when shutting down ReactOS in qemu. I've seen it personally and heard reports of it, but since it locks up qemu so bad you can't free the mouse, no one has gotten a trace (that I am aware of). * Gunnar's win32k changes introduced several bugs, many of which were fixed, but I still feel unsure about others that may be hiding. * Hartmut fixed the MP build. See, I didn't even know that was broken. I would like to freeze the tree for 72 hours, over the weekend, allowing bugfixes only. I think we all need to grab a fresh copy and run it under every platform we have, checking all the options. According to the rules set forth, I need three developers. Who agrees to a trunk freeze?

7 11

RE: [ros-dev] Problem with compiling 17859
by Ge van Geldorp 17 Sep '05

17 Sep '05

> From: Ge van Geldorp > > Complaints to alex It turns out there was a communication problem between Alex and myself. A little background: in r17811 Alex introduced a line in an asm file which failed to compile on older binutils. I talked to him about this on IRC and proposed a workaround. The communication problem was that I thought he rejected the workaround, while Alex thought he ok'ed the workaround and thought I would make the change. Result: workaround not applied and 2 people pissed-off at each other. My apologies to Alex for the remark quoted above, which was inappropriate even if he hadn't agreed to the workaround. Ge van Geldorp.

1 0

Disassempler
by Rick Langschultz 17 Sep '05

17 Sep '05

Does anyone have any examples of a disassembler or decompiler that I could use for my ReactOS program I am writing... Does anyone know about a disassembler or decompiler for Mac OS X also? Rick Langschultz rlangschultz(a)cox.net (Home) rlangschultz(a)ellemaespa.com (Work) rlangschultz(a)email.uophx.edu (School)

2 1

set /a implementation for review
by Royce Mitchell III 17 Sep '05

17 Sep '05

recursive-descent implementation of set /a. I'm sure not all error messages are going to match MS's exactly. I didn't really try to do that. since trunk is frozen, I'm submitting this patch for anybody that wants to review. I'll commit it Monday evening (if I have time) pending any suggestions for improvements or bug-fixes, etc that ppl may have for it. Index: set.c =================================================================== --- set.c (revision 17890) +++ set.c (working copy) @@ -35,6 +35,8 @@ */ #include <precomp.h> +#include <malloc.h> +#include <stdio.h> #include "resource.h" #ifdef INCLUDE_CMD_SET @@ -43,7 +45,15 @@ /* initial size of environment variable buffer */ #define ENV_BUFFER_SIZE 1024 +static BOOL +seta_eval ( LPCTSTR expr ); +static LPCTSTR +skip_ws ( LPCTSTR p ) +{ + return p + strspn ( p, " \t" ); +} + INT cmd_set (LPTSTR cmd, LPTSTR param) { TCHAR szMsg[RC_STRING_MAX_SIZE]; @@ -83,6 +93,12 @@ return 0; } + if ( !_tcsnicmp (param, _T("/A"), 2) ) + { + // TODO FIXME - what are we supposed to return? + return seta_eval ( skip_ws(param+2) ); + } + p = _tcschr (param, _T('=')); if (p) { @@ -124,4 +140,386 @@ return 0; } +static INT +ident_len ( LPCTSTR p ) +{ + LPCTSTR p2 = p; + if ( __iscsymf(*p) ) + { + ++p2; + while ( __iscsym(*p2) ) + ++p2; + } + return p2-p; +} + +#define dup_ident(p) _tcsncpy_s(alloca((ident_len(p)+1)*sizeof(TCHAR)), p, +#define PARSE_IDENT(ident,identlen,p) \ + identlen = ident_len(p); \ + ident = (LPTSTR)alloca ( ( identlen + 1 ) * sizeof(TCHAR) ); \ + memmove ( ident, p, identlen * sizeof(TCHAR) ); \ + ident[identlen] = 0; + +static BOOL +seta_identval ( LPCTSTR ident, INT* result ) +{ + // get size of buffer for env var + LPTSTR buf; + DWORD dwBuffer = GetEnvironmentVariable ( ident, NULL, 0 ); + // if GetEnvironmentVariable() fails, it returns 0 + if ( !dwBuffer ) + { + // TODO FIXME - is it correct to report a value of 0 for non-existant variables? + *result = 0; + return FALSE; + } + buf = (LPTSTR)alloca ( dwBuffer * sizeof(TCHAR) ); + if ( !buf ) + { + // TODO FIXME - is it correct to report 0 when report resources low... should we error somehow? + *result = 0; + return FALSE; + } + GetEnvironmentVariable ( ident, buf, dwBuffer ); + *result = atoi ( buf ); + return TRUE; +} + +static BOOL +calc ( INT* lval, TCHAR op, INT rval ) +{ + switch ( op ) + { + case '*': + *lval *= rval; + break; + case '/': + *lval /= rval; + break; + case '%': + *lval %= rval; + break; + case '+': + *lval += rval; + break; + case '-': + *lval -= rval; + break; + case '&': + *lval &= rval; + break; + case '^': + *lval ^= rval; + break; + case '|': + *lval |= rval; + break; + default: + printf ( "Invalid operand.\n" ); + return FALSE; + } + return TRUE; +} + +static BOOL +seta_assignment ( LPCTSTR* p_, INT* result ); + +static BOOL +seta_unaryTerm ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + if ( *p == '(' ) + { + INT rval; + p = skip_ws ( p + 1 ); + if ( !seta_assignment ( &p, &rval ) ) + return FALSE; + if ( *p != ')' ) + { + _tprintf ( _T("Expected ')'\n") ); + return FALSE; + } + p = skip_ws ( p + 1 ); + *p_ = p; + return TRUE; + } + if ( isdigit(*p) ) + { + *result = atoi ( p ); + p = skip_ws ( p + strspn ( p, "1234567890" ) ); + } + else if ( __iscsymf(*p) ) + { + LPTSTR ident; + INT identlen; + PARSE_IDENT(ident,identlen,p); + if ( !seta_identval ( ident, result ) ) + return FALSE; + } + else + { + _tprintf ( _T("Expected number or variable name\n") ); + return FALSE; + } + *p_ = p; + return TRUE; +} + +static BOOL +seta_mulTerm ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + TCHAR op = 0; + INT rval; + if ( _tcschr(_T("!~-"),*p) ) + { + op = *p; + p = skip_ws ( p + 1 ); + } + if ( !seta_unaryTerm ( &p, &rval ) ) + return FALSE; + switch ( op ) + { + case '!': + rval = !rval; + break; + case '~': + rval = ~rval; + break; + case '-': + rval = -rval; + break; + } + + *result = rval; + *p_ = p; + return TRUE; +} + +static BOOL +seta_addTerm ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + INT lval; + if ( !seta_mulTerm ( &p, &lval ) ) + return FALSE; + while ( *p && _tcschr(_T("*/%"),*p) ) + { + INT rval; + TCHAR op = *p; + + p = skip_ws ( p+1 ); + + if ( !seta_mulTerm ( &p, &rval ) ) + return FALSE; + + if ( !calc ( &lval, op, rval ) ) + return FALSE; + } + + *result = lval; + *p_ = p; + return TRUE; +} + +static BOOL +seta_logShiftTerm ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + INT lval; + if ( !seta_addTerm ( &p, &lval ) ) + return FALSE; + while ( *p && _tcschr(_T("+-"),*p) ) + { + INT rval; + TCHAR op = *p; + + p = skip_ws ( p+1 ); + + if ( !seta_addTerm ( &p, &rval ) ) + return FALSE; + + if ( !calc ( &lval, op, rval ) ) + return FALSE; + } + + *result = lval; + *p_ = p; + return TRUE; +} + +static BOOL +seta_bitAndTerm ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + INT lval; + if ( !seta_logShiftTerm ( &p, &lval ) ) + return FALSE; + while ( *p && _tcschr(_T("<>"),*p) && p[0] == p[1] ) + { + INT rval; + TCHAR op = *p; + + p = skip_ws ( p+2 ); + + if ( !seta_logShiftTerm ( &p, &rval ) ) + return FALSE; + + if ( !calc ( &lval, op, rval ) ) + return FALSE; + } + + *result = lval; + *p_ = p; + return TRUE; +} + +static BOOL +seta_bitExclOrTerm ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + INT lval; + if ( !seta_bitAndTerm ( &p, &lval ) ) + return FALSE; + while ( *p == _T('&') ) + { + INT rval; + + p = skip_ws ( p+1 ); + + if ( !seta_bitAndTerm ( &p, &rval ) ) + return FALSE; + + lval &= rval; + } + + *result = lval; + *p_ = p; + return TRUE; +} + +static BOOL +seta_bitOrTerm ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + INT lval; + if ( !seta_bitExclOrTerm ( &p, &lval ) ) + return FALSE; + while ( *p == _T('^') ) + { + INT rval; + + p = skip_ws ( p+1 ); + + if ( !seta_bitExclOrTerm ( &p, &rval ) ) + return FALSE; + + lval ^= rval; + } + + *result = lval; + *p_ = p; + return TRUE; +} + +static BOOL +seta_expr ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + INT lval; + if ( !seta_bitOrTerm ( &p, &lval ) ) + return FALSE; + while ( *p == _T('|') ) + { + INT rval; + + p = skip_ws ( p+1 ); + + if ( !seta_bitOrTerm ( &p, &rval ) ) + return FALSE; + + lval |= rval; + } + + *result = lval; + *p_ = p; + return TRUE; +} + +static BOOL +seta_assignment ( LPCTSTR* p_, INT* result ) +{ + LPCTSTR p = *p_; + LPTSTR ident; + TCHAR op = 0; + INT identlen, exprval; + + PARSE_IDENT(ident,identlen,p); + if ( identlen ) + { + if ( *p == _T('=') ) + op = *p, p++; + else if ( _tcschr ( _T("*/%+-&^|"), *p ) && p[1] == _T('=') ) + op = *p, p += 2; + else if ( _tcschr ( _T("<>"), *p ) && *p == p[1] && p[2] == _T('=') ) + op = *p, p += 3; + else + { + _tprintf ( _T("Missing operand.\n") ); + return FALSE; + } + p += strspn ( p, " \t" ); + } + + if ( !seta_expr ( &p, &exprval ) ) + return FALSE; + + if ( identlen ) + { + INT identval; + LPTSTR buf; + + if ( !seta_identval ( ident, &identval ) ) + return FALSE; + if ( op == '=' ) + identval = *result; + else if ( !calc ( &identval, op, exprval ) ) + return FALSE; + buf = (LPTSTR)alloca ( 32 * sizeof(TCHAR) ); + _sntprintf ( buf, 32, _T("%i"), identval ); + SetEnvironmentVariable ( ident, buf ); // TODO FIXME - check return value + exprval = identval; + } + + *result = exprval; + *p_ = p; + return TRUE; +} + +static BOOL +seta_eval ( LPCTSTR p ) +{ + INT rval; + if ( !*p ) + { + _tprintf ( _T("The syntax of the command is incorrect.\n") ); + return FALSE; + } + for ( ;; ) + { + if ( !seta_assignment ( &p, &rval ) ) + return FALSE; + if ( !*p ) + break; + if ( *p != _T(',') ) + { + _tprintf ( _T("Missing operator.\n") ); + return FALSE; + } + ++p; // skip comma + } + _tprintf ( _T("%i\n"), rval ); + return TRUE; +} + #endif

2 1

Problem with compiling 17859
by Saveliy Tretiakov 17 Sep '05

17 Sep '05

What's this? [GAS] lib\rtl\i386\except.s lib\rtl\i386\except.s: Assembler messages: lib\rtl\i386\except.s:207: Error: Unrecognized token `|4)' lib\rtl\i386\except.s:207: Error: Unexpected token `' lib\rtl\i386\except.s:232: Error: Unrecognized token `|4)' lib\rtl\i386\except.s:232: Error: Unexpected token `' make: *** [obj-i386\lib\rtl\i386\except.o] Error 1

5 6

Anyone looking for a nice, uncomplicated bug to fix?
by Ge van Geldorp 16 Sep '05

16 Sep '05

Bug 775 (http://www.reactos.com/bugzilla/show_bug.cgi?id=775) seems to be a simple application bug. I expect no kernel involvement at all. So, if you were always wanting to fix something in ReactOS but were afraid it might be too complicated, this bug is for you. It should give you experience in building and debugging ReactOS so maybe next time you can attack something a little bit more complicated. Gé van Geldorp.

1 0

Re: [ros-diffs] [hbirr] 17863: Fixed the MP build.
by Alex Ionescu 16 Sep '05

16 Sep '05

hbirr(a)svn.reactos.com wrote: >Fixed the MP build. > Hi Hartmut, I'm really sorry, I forgot to test MP=1 :( We really need a way to ensure that KDBG/MP code always gets built... it would cause less problems... Best regards, Alex Ionescu

1 0

Re: [ros-diffs] [ion] 17860: Return valid status
by Hartmut Birr 15 Sep '05

15 Sep '05

ion(a)svn.reactos.com wrote: >Return valid status > >Modified: trunk/reactos/lib/rtl/exception.c > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/lib/rtl/exception.c* > >--- trunk/reactos/lib/rtl/exception.c 2005-09-15 13:25:32 UTC (rev 17859) >+++ trunk/reactos/lib/rtl/exception.c 2005-09-15 14:07:37 UTC (rev 17860) >@@ -39,10 +39,10 @@ > > Context.ContextFlags = CONTEXT_FULL; > > /* Check if we're being debugged (user-mode only) */ > > >- if (!RtlpCheckForActiveDebugger()) > > >+ if (!RtlpCheckForActiveDebugger(TRUE)) > > RtlpCheckForActiveDebugger is defined as BOOLEAN NTAPI RtlpCheckForActiveDebugger(VOID); - Hartmut

1 0

I/O subsystem question
by Ge van Geldorp 15 Sep '05

15 Sep '05

I'm working on bug 713 (http://www.reactos.com/bugzilla/show_bug.cgi?id=713 for the click-happy). What I have found is this: - Telnet opens a socket - Sending and receiving are handled by different threads, let's call them S and R - Thread R starts a recv() operation, which is translated to an ioctl on the socket - No data is available, so thread R blocks, waiting for FileObject->Event - I type something, which is handled by thread S. Thread S starts a send() operation. - Again translated to an ioctl on the socket. Since this is the same socket as used by S, the FileObject will be the same - The send can complete immediately, IoCompleteRequest is called which sets the FileObject->Event. - Thread R is unblocked, the event it was waiting for was set by thread S. However, the irp of thread R was never completed. The recv() call returns with bogus info. - Thread R starts another recv(). When some data arrives from the server, two irps are waiting for it. This eventually leads to the crash. The fundamental problem seems to be multiple overlapping I/O operations which all use FileObject->Event to signal their completion. I have no idea how to fix that... Gé van Geldorp.

5 8

Non-working uxtheme.dll
by Mike Swanson 14 Sep '05

14 Sep '05

I'm sorry if this would a wrong place to post this, but since I'm trying the ReactOS uxtheme.dll, I figured this would be fine. I've compiled today's SVN, and I noticed that ReactOS had a uxtheme.dll (didn't know that before :P). Well, as a try, I went and put it on a Windows XP Professional machine (no service pack, and the Microsoft uxtheme.dll is un-patched). When I rebooted with the ReactOS DLL, Windows XP freezes at the welcome screen, the start up sound doesn't even play. So I'm wondering if uxtheme.dll isn't complete yet or if it's already known to have problems. -- Mike

6 7

freeldr questions
by vit-ros＠att.net 14 Sep '05

14 Sep '05

Few questions about freeldr - Is there a compelling reason to have pointer members of LOADER_PARAMETER_BLOCK such as ModsAddr as ULONGs ? (include/ndk/haltypes.h) - Why the kernel module (ntoskrnl.exe) in not treated as such in the loader (there is a special case to create the corresponding module object in the kernel) ? - Why MachGetMemoryMap() is called twice: in freeldr/mm/meminit.c and in freeldr/reactos/reactos.c ? - wouldn't it be nicer to fix these ?

1 0

WaitNamedPipe bug? can anyone confirm?
by Luke Kenneth Casson Leighton 14 Sep '05

14 Sep '05

is WaitNamedPipe working, or have i got something wrong in my code? this is 0.2.7. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

msafd headers
by Mikhail Y. Zvyozdochkin 14 Sep '05

14 Sep '05

Hi All! Files on reactos/lib/msafd/misc/ uses header "msafd.h" from reactos/lib/msafd/. On my system, MinGW/linux successfully compiled these files ONLY after I manually corrected include directive: #include <../msafd.h> instead #include <msafd.h> in all 5 *.c files in reactos/lib/msafd/misc/. Maybe we must make this replacement in svn tree? Or it was my misconfiguration? ;) WBR, DarkHobbit

3 3

Testing ROS on VMWare With 32MB... Interesting Results
by TwoTailedFox 14 Sep '05

14 Sep '05

Been having a poke around, it seems neither LiveCD nor BootCD will boot into GUI (Using latest HEAD SVN), on 32MB. BootCD will complete first stage installer, but won't boot into GUI to load the second stage setup. LiveCD immediately hangs. Now, on VMWare, I use Other/Other as the OS Category, and I've been hearing some (like WaxDragon), using Windows XP Professional as the OS Category. I obtained a BootCD of 17751 rev, and tried it on the WinXP setting, using 32MB. First time I tried it, it hung at copying ole32.dll (34%). Second time, I got a STOP error during the file transfer. Third time, however, it completed the first stage fine. The only difference between the Other and WinXP Pro settings is the inclusion of a USB Controller. I added one to my "Other" setup, and ROS, again, installed fine first time around on 32MB. Now, for the interesting bit. The error is a pretty constant one, and it complains of No Memory Pages Available. It seems just common to the GUI, seeing as ROS won't boot on 32MB even once Setup is completed. This is the case for both SVN Live and BootCD's. Something in the GUI is causing a leak -- "I had a handle on life, but then it broke"

5 6

NamedPipes - cause massive reliability problems with services. what to _do_?
by Luke Kenneth Casson Leighton 14 Sep '05

14 Sep '05

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ipc/base/m… please note the comments "it is possible for a client to connect in between the CreateNamedPipe and ConnectPipe". in other words, NamedPipes don't have any equivalent of "listen()". this is a massive _massive_ problem, evidence of which i first encountered with "rpctorture --processes=100 --repeat-operation=100", back in 1998. out of 10,000 operations performed across 100 processes, about TWENTY of those operations would succeed. that's a success rate of 0.2%. (anyone who runs a lab where 400 students sit down at the beginning of a session and all log in to the same NT PDC will tell you _exactly_ what they bloody think of windows and it's the same issue) the reason why there is such an abysmal failure rate was not clear to me until today. it's due - quite simply - to this delay. if the server is particularly overloaded (due to having to deal with, oh i dunno, say, a large influx of incoming Named Pipe client requests) then the time delay between CreateNamedPipe and ConnectPipe is increased; if some idiot decides that the number of pipe connections is to be limited; if someone decides that the number of threads is to be limited, then the server quickly goes into meltdown. if there is protocol proxying or authentication going on (as is the case of SMB IPC$ providing MSRPC named pipes - ncacn_np for those people who know what that is) then you _really_ are in trouble. the question is: having access to the source code - in reactos - what can be _done_ about this? would it be reasonable to write - and use - a named pipes equivalent of "listen()"? alternatively, how in hell's name do you _deal_ with this sort of thing? l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

Cant Install Self Compiled ISO
by Brandon Turner 13 Sep '05

13 Sep '05

I can't install any bootcd's that I compile, gives INACCESSIBLE_BOOT_DEVICE. This happens in Qemu, vmware, and virtual pc. I have done full clean builds by doing "make clean" and deleting the object/output folders. I don't know when this started happening really. But if i download the ISO off of CIA then its fine, the exact same version. I am compiling on Windows XP with ROSBe. Here is a link to a picture of the crash: www.brandonturner.org/crash.PNG Please help, its driving me crazy! Brandon

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev