ReactOS.Bugzilla(a)reactos.org wrote:
> http://www.reactos.org/bugzilla/show_bug.cgi?id=1431
>
> Summary: Regression of setup
> Product: ReactOS
> Version: unspecified
> Platform: VMWare 5
> OS/Version: ReactOS
> Status: NEW
> Severity: normal
> Priority: P3
> Component: Win32
> AssignedTo: ros-bugs(a)reactos.org
> ReportedBy: email1562000(a)yahoo.com
> QAContact: ros-bugs(a)reactos.org
>
>
> filezilla FTP server setup works properly in build 21454(apr-8-2006) but in
> build 21725(apr-25-2006) all the drop down lists just show a series of squares
> where text should be displayed.
>
>
Could you post pics to the bug list?
Thanks,
James
On Fri, Apr 21, 2006 at 01:52:58PM -0700, Roland McGrath wrote:
> Have you considered instead using standard features as specified in POSIX
> since around 1996?
dce predates the posix standards - that's why all dce projects, some of
them multi-hundred-million-dollar projects by ibm, fujitsu, EDS etc -
have had to use posix draft 4 threading.
the opengroup developers had to make a decision: they couldn't wait
around for a few years while the POSIX committee made up their minds.
so all the companies who were running dce/rpc applications had to write
POSIX Draft 4 threading libraries for their operating systems.
ibm did it. sun microsystems did it. microsoft did it (Win32 threads)
when they ported the BSD-compatible OSF/1.0 licensed DCE 1.1 reference
implementation to win32, as the basis of MSRPC.
> What's your plan for other POSIX systems, such as Solaris?
forget solaris: sun microsystems can deal with solaris.
linux is the innovation leader, now, not solaris.
> If you don't want to cancel threads as cancellation is defined by POSIX,
> then why use cancellation instead of another mechanism that matches your needs?
[long answers first, short one at end]
because, despite being an absolutely critical strategic project that
could save key strategic free software projects who are _not_ using it
about a man-decade of development effort _each_, there is absolutely
zero recognition of this and therefore absolutely zero funding of the
project.
luke howard uses freedce for his XAD project, which is a (proprietary)
Active Directory replacement that he released THREE YEARS ago (and the
samba team _still_ haven't got an active directory server replacement
yet).
XAD is capable of running on IBM z390 mainframes, and luke howard
has won business awards for his work.
because, as it is "old" code, with a very archaic and interesting
development history, it needs work to be brought up-to-date. and
because it needs work, and _because_ it is so very comprehensive
in what it does, people misunderstand and do not appreciate its
complexity, and therefore think, "i can do better than this", and
fail miserably, and so it gets ignored.
the gist is this: the use of cancellation is embedded very deeply into
the design of this code.
and there isn't anyone with the time, money, resources or
immediately-available knowledge to rip a quarter of a million lines of
code apart looking for a way to shoe-horn some very complex and subtle
interaction _out_ of freedce so that it fits nicely with POSIX.
anyone think i should try to put the "emulation" bit back
into dcethreads (to re-wrap the cancellation rules of posix
draft 4 but to keep the new API) and write redhat off (just
like charles advised right at the beginning of this thread),
let me know.
l.
> http://www.reactos.org/bugzilla/show_bug.cgi?id=1300
>
>
> greatlord(a)reactos.com changed:
>
> What |Removed |Added
> --------------------------------------------------------------
> --------------
> Status|REOPENED |RESOLVED
> Resolution| |INVALID
>
>
>
>
> ------- Additional Comments From greatlord(a)reactos.com
> 2006-04-20 16:45 CET -------
> This is not a vaild bug report, each program is response for
> the icon for the
> file format
>
Sorry to reply directly to this, but I don't have web access at the moment.
The above is not true. Some default file icons are controled by the
operating system, like .txt, .jpg, or .bmp for example. They can be
over-ridden by 3rd party apps.
This is a valid bug report.
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
On Thu, Apr 20, 2006 at 03:04:21PM +1000, Luke Howard wrote:
luke, you are a star: thank you for helping out with this.
just for people's information (in case it's not been mentioned here - i
must admit i forgot to notify opendce(a)opengroup.org!)
about 6-8 months ago i did a coding-spree on freedce, with a view to
achieving two, maybe three, major things:
1) porting to win32 (if you use pthreads-win32)
2) using posix final draft (7?) threads not posix draft 4.
3) proving to the people on wine and reactos that they have
a hell of a lot of work to do (measured in man-decades)
by not using the open group's DCE/RPC reference
implementation.
here's the gotchas that i encountered, and had to give up:
- udp worked, but tcp did not
- reactos had some problems at the time with the code behind
ipconfig.exe (NetTransportEnum i think it was)
- pthreads-win32 was too strictly posix compliant (!)
and there is a cancellation exception or something which
makes it fail in the dcethreads exception library tests,
where linux does not fail (!)
maybe this is related to what lukeh is talking about.
*shrug*.
anyway, the upshot is that freedce/latest-cvs also doesn't work
on TCP, and thank you so much people for helping track down why.
it's only been ten years so far: hopefully some time within the next
decade, freedce will be used for some real MSRPC-related free
software projects.
l
> >In rpc__cn_network_receiver(), rpc__socket_close() is called without an
> >exception handler in place. According to IEEE Std 1003.1 (2004), close()
> >is a cancellation point, see:
> >
> >http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html
> >
> >Given this, a receiver thread could receive a cancel whilst closing the
> >socket, which will cause to entire program to abort. (We have seen this
> >occur when the RPC server is under load.)
> >
> >A suggested fix is to move the call to rpc__socket_close() inside the
> >TRY/CATCH_ALL block that removes any pending cancels.
>
> It seems like the real fix is to disable cancellation within
> rpc__socket_close(), because in other places the OSF code appears to
> assume that this is not a cancellation point.
>
> Ditto for open(), socket(), etc (but not I/O routines that may block).
>
> I should note that the Linux dcethreads library does actually disable
> cancellation for these calls, however in our own DCE thread library
> we opted not to override any system calls to avoid changing semantics
> when used by non-DCE code.
>
> -- Luke
>
> --
>
--
--
lkcl.net - mad free software computer person, visionary and poet.
--
I just did some digging around, and this issue was introduced
somewhere between 20902 and 20911. Alex was working on the kernel
heavily at the time, and there are several intertwined commmits IIRC.
I just tested 20902 with both kqemu (and -kernel-kqemu) and it
installed fine, and ran as well as I remember it did. It was
noticably faster.
On 4/17/06, WaxDragon <waxdragon(a)gmail.com> wrote:
> This bug has been around for a while.
>
> On 4/17/06, Víctor Córcoles López <vcorcoles25(a)hotmail.com> wrote:
> > Reactos 0.3.0 SVN + kqemu fails as guest O.S. It fails in both systems,
> > Linux host and Windows Host. Without kqemu the reactos 0.3.0 SVN runs with
> > less bugs.
> >
> > In VMWARE host, this bug not apear.
> >
> > I Send a screenshot of failure.
> >
WD
--
ReactOS is a hub, follow the spokes and you'll
immediately find absolutely everything you need
to know about Windows. ReactOS is not just
software, it's people.
kjk_hyperion
greatlrd(a)svn.reactos.org wrote:
> Author: greatlrd
> Date: Sun Apr 16 20:04:28 2006
> New Revision: 21611
>
> URL: http://svn.reactos.ru/svn/reactos?rev=21611&view=rev
> Log:
> kjk_hyperion : "Breaking auditing lock for a temporary fix: allow ExEnterCriticalRegionAndAcquireFastMutexUnsafe and ExReleaseFastMutexUnsafeAndLeaveCriticalRegion to be called from any thread; fixes UserEnterShared, UserEnterExclusive and UserLeave in win32k"
>
> Modified:
> trunk/reactos/ntoskrnl/ex/fmutex.c
>
> Modified: trunk/reactos/ntoskrnl/ex/fmutex.c
> URL: http://svn.reactos.ru/svn/reactos/trunk/reactos/ntoskrnl/ex/fmutex.c?rev=21…
This fix is broken. The real problem is win32k, you should fix that instead.
Best regards,
Alex Ionescu
> From: greatlrd(a)svn.reactos.org
>
> Log:
> fix 16 to 16 soyrce dest why the hell does th 16bitmap surface calls
> into this
The "16 -> 16 copy" in the DPRINT1 is a copy/paste mistake, it should read "24 -> 24 copy". Your fix is incorrect. What needs to be done in this case is process one pixel at a time, calling XLATEOBJ_iXlate on each one.
GvG
Hi. I'm trying to debug ros with gdb (according to GvG's tutorial) and I
have a problem. After I attach gdb, reactos boots into desktop and then
freezes with endless sigservs. Mouse cursor is not moving. Any ideas?
(gdb) target remote localhost:567
Remote debugging using localhost:567
0x800a8297 in ?? ()
(gdb) continue
Continuing.
*** Now ros boots into desktop. ***
Program received signal SIGSEGV, Segmentation fault.
0x0040aa12 in ?? ()
(gdb) continue
Continuing.
Can't send signals to this remote system. SIGSEGV not sent.
Program received signal SIGSEGV, Segmentation fault.
0x0040aa12 in ?? ()
(gdb) continue
Continuing.
Can't send signals to this remote system. SIGSEGV not sent.
Program received signal SIGSEGV, Segmentation fault.
0x0040aa12 in ?? ()
......
> [CC] dll/win32/wininet/cookie.c
> [CC] dll/win32/wininet/dialogs.c
> [CC] dll/win32/wininet/ftp.c
> [CC] dll/win32/wininet/gopher.c
> [CC] dll/win32/wininet/http.c
> dll/win32/wininet/http.c:62:23: inet_ntop.c: No such file or directory
> dll/win32/wininet/http.c: In function `HTTP_HttpOpenRequestW':
> dll/win32/wininet/http.c:1154: warning: implicit declaration of
> function `inet_ntop'
> make: *** [obj-i386/dll/win32/wininet/http.o] Error 1
It looks like it's trying to include a file that doesn't exist. Maybe
somebody forgot to run "svn add inet_ntop.c" before they committed their
changes?
> From: Gunnar Modin <gunnar.modin(a)telia.com>
> Sent: Saturday, April 15, 2006 21:31
> To: ros-dev-owner(a)reactos.org
> Subject: React OS
>
> I just woder if there is any way I can perticipate in the
> development of the OS.
>
> I have an masterthesis to do on my education at the Mid
> Sweden university.
> The project shell due for about four mounth on full time. The
> plan is to do it on half time the coming winter.
>
> The topics that I have studied are Distributed Systems and
> Networkning.
> I have jused both C++ and Java as programming laguage. I also
> did an projekt in Distrubuted system regarding XML and acess.
> In Networking I studied IPv6 in more detail.
>
> Best regards
>
> Gunnar Modin
>