Hi Arty!
On Sun, Feb 15, 2009 at 4:52 PM, <arty(a)svn.reactos.org> wrote:
> URL: http://svn.reactos.org/svn/reactos?rev=39613&view=rev
> Log:
> Fix loopback adapter locking and make traffic work consistently.
> Fix zero-address binding.
> Local tcp services should work now.
I take this to mean telnetd should be talking on the network now?
Hello remote process control and the 1980's!
Thanks a lot of looking in to this. When I have time I am going to do
further cleanup of telnetd and move it in to the ReactOS tree proper.
Next on my list is a tftp server I found which I will attempt to get
license clarification on, cleanup and add to ReactOS so that we can
look in to using ReactOS tftpd to support kickstart like deployment
with netboot.
Thanks
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Hi,
I know this is in a branch, but~
WINAPI
DdUnlock(LPDDHAL_UNLOCKDATA Unlock)
{
+ /* Fixme for opengl hel emulations */
+ HEL_OGL_STUB;
+#if 0
/* Call win32k */
return NtGdiDdUnlock((HANDLE)Unlock->lpDDSurface->hDDSurface,
(PDD_UNLOCKDATA)Unlock);
+#endif
}
It is a direct call and this is correct. Why if it out? Don't add non
standard functionality to the gdi interface unless this is a upgrade
from XP.
Thanks,
James
Hello everyone,
A new release of RosBE-Unix is finally available.
It mostly features updated build tools compatible to the versions used in
RosBE-Windows 1.4 and initial multi-architecture support through additional
RosBE-Unix packages (which still don't exist though :P)
I highly recommend the update, because our previous binutils contains a
critical bug in dlltool. (see
http://sourceware.org/bugzilla/show_bug.cgi?id=9766 for details)
Some components affected by that bug were our msvcrt*.dll and mapi32.dll.
The new release is now available from SourceForge, just like RosBE-Windows
(https://sourceforge.net/project/showfiles.php?group_id=6553&package_id=3084
58)
Best regards,
Colin
Hello everyone,
Recently, the problem came up that Wine's spoolss.dll tries to forward its
"EnumPortsW" function to the similar function in winspool.drv.
Wine added a forward entry "winspool.drv.EnumPortsW" for this reason.
Unfortunately, such forwarders weren't supported by binutils, thus Christoph
opened this bug for them:
http://sourceware.org/bugzilla/show_bug.cgi?id=9811
The provided patch now makes such entries possible in the .def file, but
that still doesn't help as Windows' and ReactOS' ntdll both forward to .dll
files only.
So after all, this non-dll forwarding thing seems to be a Wine invention we
cannot support and have to avoid when importing Wine stuff.
Additionally, the proposed patch on the binutils Bugzilla won't find its way
into RosBE now.
Best regards,
Colin
Considering about 6 of you went to FOSDEM, is anyone actually gonna release
any info about what happened?
If I am completely unaware, I can imagine how expectant users feel
Communication is really terrible.
Ged.
Please add a standard header, with license information.
On Feb 11, 2009, at 11:37 PM, tkreuzer(a)svn.reactos.org wrote:
> Author: tkreuzer
> Date: Wed Feb 11 14:37:25 2009
> New Revision: 39558
>
> URL: http://svn.reactos.org/svn/reactos?rev=39558&view=rev
> Log:
> Implement hpp - the header preprocessor
> It can parse headers and create new headers from them based on a
> simple prepreprocessing language that's compatible with the C
> preprocessor, so the source file stays a valid header. It works,
> but doesn't yet support different folders.
>
> Added:
> trunk/reactos/tools/hpp/ (with props)
> trunk/reactos/tools/hpp/hpp.c (with props)
> trunk/reactos/tools/hpp/hpp.rbuild (with props)
>
> Propchange: trunk/reactos/tools/hpp/
> ----------------------------------------------------------------------
> --------
> svn:mergeinfo =
>
> Added: trunk/reactos/tools/hpp/hpp.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/hpp/
> hpp.c?rev=39558&view=auto
> ======================================================================
> ========
> --- trunk/reactos/tools/hpp/hpp.c (added)
> +++ trunk/reactos/tools/hpp/hpp.c [iso-8859-1] Wed Feb 11 14:37:25
> 2009
> @@ -1,0 +1,509 @@
> +#include <stdio.h>
fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Fri Feb 13 05:20:59 2009
> New Revision: 39578
>
> URL: http://svn.reactos.org/svn/reactos?rev=39578&view=rev
> Log:
> Igor Koshpaev <tower(a)reactos.org>
> - Include missing modules into bootcd
>
...
> +modules\rostests\apitests\w32kdll\w32kdll_2k3sp2\w32kdll_2k3sp2.dll 1 optional
> +modules\rostests\apitests\w32kdll\w32kdll_2ksp4\w32kdll_2ksp4.dll 1 optional
> ...
> +modules\rostests\apitests\w32kdll\w32kdll_xpsp2\w32kdll_xpsp2.dll 1 optional
>
These make no sense on reactos. They only work on the respective OS.
Does the pspec here use Winebuild? Sorry I can't check at the moment.
If it does, the current winebuild allows you to specify exports for a
given arch by passing
-arch=cpu
in the spec file.
On Tue, Feb 10, 2009 at 10:15 AM, <tkreuzer(a)svn.reactos.org> wrote:
> Author: tkreuzer
> Date: Tue Feb 10 09:15:07 2009
> New Revision: 39533
>
> URL: http://svn.reactos.org/svn/reactos?rev=39533&view=rev
> Log:
> x64 version of ntoskrnl doesn't export ExInterlockedAddLargeStatistic
>
> Modified:
> branches/ros-amd64-bringup/reactos/ntoskrnl/ntoskrnl.pspec
>
> Modified: branches/ros-amd64-bringup/reactos/ntoskrnl/ntoskrnl.pspec
> URL: http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/ntosk…
> ==============================================================================
> --- branches/ros-amd64-bringup/reactos/ntoskrnl/ntoskrnl.pspec [iso-8859-1] (original)
> +++ branches/ros-amd64-bringup/reactos/ntoskrnl/ntoskrnl.pspec [iso-8859-1] Tue Feb 10 09:15:07 2009
> @@ -104,7 +104,9 @@
> @ stdcall ExInitializeRundownProtectionCacheAware(ptr long)
> @ stdcall ExInitializeZone(ptr long ptr long)
> @ stdcall ExInterlockedAddLargeInteger(ptr long long ptr)
> +#ifndef __x86_64__
> @ fastcall ExInterlockedAddLargeStatistic(ptr long)
> +#endif
> @ stdcall ExInterlockedAddUlong(ptr long ptr)
> #ifndef __x86_64__
> @ fastcall ExInterlockedCompareExchange64(ptr ptr ptr ptr)
>
>
--
Steven Edwards
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
Folks,
I don't know where to ask this question, So decided to ask it on Dev mailing
list.
I am new to ReactOS and installed it on VMWare workstation and really loved
it.
It's behavior look and feel is like Windows and I really appreciate it
(although there is long way to for it)
Few of my questions are below:--
1) Is there any development kit for developing applications for ReactOS?
2) If not, Will Applications developed using Windows SDK (not .net
framework and all, just plain SDK) will work on ReactOS?
3) If Apps developed on Windows works on ReactOS, Are libraries developed
for Windows (which just depend on kernel32, user32 and other system dlls)
will work on ReactOS?
I am planning to use ReactOS for one of my custom device (using x86 based
processor) and want to develop some applications on top of it.
Regards
Deepak
Hi,
I am currently having a small problem on the x64 branch, maybe someone
can help me.
In wdm.h there's the following declarations:
#if defined (_WIN64)
#if defined(_NTDRIVER_) || defined(_NTDDK) || defined(_NTIFS_) || \
defined(_NTHAL_) || defined(_NTOSP_)
NTKRNLAPI
USHORT
ExQueryDepthSList(IN PSLIST_HEADER Listhead);
#else
FORCEINLINE
USHORT
ExQueryDepthSList(IN PSLIST_HEADER Listhead)
{
return (USHORT)(ListHead->Alignment & 0xffff);
}
#endif
#else
#define ExQueryDepthSList(listhead) (listhead)->Depth
#endif
So when compiling ntoskrnl, ExQueryDepthSList is not inlined. Later in
wdm.h (currently in our winddk.h, but to be moved to wdm.h)
ExQueryDepthSList is used in ExFreeToNPagedLookasideList inline function.
But I want ExQueryDepthSList to be inlined from within ntoskrnl. The
question is how can I achieve this?
If I #define it to be inline in ntoskrnl's private headers, it will not
affect ExFreeToNPagedLookasideList.
When I declare it as an inline function after the header is included, I
get a warning that it was declared inline after being used and that a
static declaration follows a non-static. (Does anyone know hoe to
disable these stupid warnings?)
Declaring it inline before including wdm.h doesn't work, as the needed
declaration for SLIST_HEADER is missing.
Anyone got any other idea? I'd like to avoid hacking our public headers,
to keep them as compatible to ms headers as possible.
Regards,
Timo
Forwarded to ReactOS mailing list. (using correct address this time :)
----- Message d'origine ----
> De : Anthony Liguori <anthony(a)codemonkey.ws>
> À : qemu-devel(a)nongnu.org
> Envoyé le : Jeudi, 29 Janvier 2009, 22h55mn 12s
> Objet : Re: [Qemu-devel] Virtio ballon device always loaded ?
>
> Sylvain Petreolle wrote:
> > Testing ReactOS in qemu made it always asking drivers for a RAM Controller.
> >
> > Looking at "info pci" output and hw/pc.c, I see that the Virtio balloon device
> is always loaded in an x86/64 target.
> > Is that a wanted feature ?
> >
>
> Sure, as I see no harm in not enabling it by default. ReactOS doesn't
> just ignore unknown PCI devices? That's strange because Windows seems to.
>
> Regards,
>
> Anthony Liguori
>
> > I also notice that hw/virtio-balloon.c header refers to the Virtio Block
> Device.
> >
> > Kind regards,
> > Sylvain Petreolle
> >
> >
> >
> >
"Please test them, especially with the applications in Downloader, and write
your results to
http://www.reactos.org/wiki/index.php/Tests_for_0.3.8"
I have a suggestion - we should limit the amount of people that are allowed
to actually write the results to some designated people and let everyone
pass the results to them.
Hello everybody (and especially the testers),
After nobody complained about branching 0.3.8 from trunk now, I took the
initiative today and prepared the branch with our usual customizations and
hacks.
It's now again the time for application testing. Therefore I uploaded Boot
CD and Live CD of the current branch to http://reactos.colinfinck.de/
Please test them, especially with the applications in Downloader, and write
your results to http://www.reactos.org/wiki/index.php/Tests_for_0.3.8
I especially write this now, because we want the release to be ready some
days before FOSDEM.
Andrew wants to start burning the CDs for FOSDEM soon, so it would be great
if we could get the entire release done till *next Monday*.
Best regards,
Colin