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
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...
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>
--
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>
--
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?
> 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.
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)