Hello,
after updating to r29681, I cannot compile ROS.
The error is:
[WRC] obj-i386\base\applications\cacls\cacls.coff
output-i386\tools\wrc\wrc.exe: unknown option -- W
output-i386\tools\wrc\wrc.exe: unknown option -- n
output-i386\tools\wrc\wrc.exe: unknown option -- W
output-i386\tools\wrc\wrc.exe: unknown option -- p
Error: Too many output files.
mingw32-make: *** [obj-i386\base\applications\cacls\cacls.coff] Error 2
Sincerely,
Carlo Bramini
Hi Marc,
the patch / bug IS valid, Magnus made a mistake and closed it.
I wanted to do the same, but it's rather timeconsuming, so I
appreciate you took the first steps. Still, some modules may require
setting some specific version - that's allright, we can leave some
exceptions for now, but otherwise, version number should be set
globally, not in every .rbuild file (which is so wrong).
WBR,
Aleksey Bragin.
On Oct 19, 2007, at 2:53 AM, Marc Piulachs wrote:
> Hi,
>
> On the reactos frontpage I see that the project aims to reimplement
> WindowsXP , that is NT 5.2 , but currently most of the modules
> define their
> own target version ranging from NT4 to NT 5.3 (2003) .On recent
> shell32
> commits I have even seen someone introducing Vista-only APIs.
>
> I think an effort has to be done to fix that situation ,IMHO targeting
> multiple windows versions is fine but not a mix of them so I
> recently posted
> a bug report on mozilla to have it present at least.
> http://www.reactos.org/bugzilla/show_bug.cgi?id=2745 but It has
> been marked
> as invalid and I can't understand the reason given, I may be wrong
> about
> that but I'd like to know what I'm missing here, can anyone clarify?
>
> /Marc
Shouldn't it be finally fixed, instead?
I don't know who broke it. Was it Magnus with the "No PNP videocard"
commit?
WBR,
Aleksey Bragin.
On Oct 18, 2007, at 8:01 AM, mnordell(a)svn.reactos.org wrote:
> Author: mnordell
> Date: Thu Oct 18 08:01:53 2007
> New Revision: 29653
>
> URL: http://svn.reactos.org/svn/reactos?rev=29653&view=rev
> Log:
> Patch from aicommander. Actually copy uniata.sys from the
> installation media, and disable VGA resolution selection as VGA is
> broken.
> [Display]
> ;<id> = <user friendly name>,<spare>,<service key
> name>,<hight>,<width>,<bpp>
> -vga = "VGA Display (640x480x4)",,Vga,640,480,4
> +;vga = "VGA Display (640x480x4)",,Vga,640,480,4
It's in the User FAQ - third-last question, at the end of the answer it
says:
"Other virtual machines/x86 emulators should be able to run ReactOS as
well, and ReactOS is known to run in at least Bochs, VMWare, VirtualPC
and QEMU. If you know of other virtual machines that support it, please
send an e-mail to the ros-dev mailing list."
I didn't see any mention of it in the recent archives of the mailing
list, so I thought I'd mention it.
Sorry if I misunderstood. Perhaps I'll try out the other emulation
tools, though I've found VirtualBox in general to be very easy to use.
Regards,
Mike
Zachary Gorden wrote:
>First, which FAQ?
>
>Second, I'll talk with Colin about it. Some of the devs don't like >vbox,
>but so long as we can get it to work, it's more or less up to the >release
>engineers and Aleksey what vm images to release.
>
>Z98
>Release Engineer (secondary)
>
Hello list,
As recommended in the FAQ, I thought I'd mention that I gave ReactOS a
try as a virtual machine using VirtualBox (http://www.virtualbox.org),
and it seems to work okay. It wouldn't be too difficult to post a
VirtualBox virtual disk image file, though it only took a couple minutes
to setup from the installation CD image.
I'd like to know if anyone else has given it a try though, as I had some
stability problems (random freezes, etc.).
I look forward to the future releases of ReactOS.
Regards,
Mike
This is a hack that shouldn't be there. This is csrss' responsibility.
- Thomas
tkreuzer(a)svn.reactos.org wrote:
> Author: tkreuzer
> Date: Tue Oct 16 02:23:42 2007
> New Revision: 29617
>
> URL: http://svn.reactos.org/svn/reactos?rev=29617&view=rev
> Log:
> If cmd was started from a shortcut, use the shortcut's name as window title, else use executable name, like on windows. Doesn't work on ros atm, due to bug 2743, but works on win XP. So if'ed out atm.
>
> Modified:
> trunk/reactos/base/shell/cmd/cmd.c
>
> Modified: trunk/reactos/base/shell/cmd/cmd.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/cmd/cmd.c?rev=2…
> ==============================================================================
> --- trunk/reactos/base/shell/cmd/cmd.c (original)
> +++ trunk/reactos/base/shell/cmd/cmd.c Tue Oct 16 02:23:42 2007
> @@ -1603,6 +1603,53 @@
> }
> #endif
>
> +void
> +InitTitle()
> +{
> + STARTUPINFOW StartupInfo;
> + LPWSTR lpFileName;
> + WCHAR szTitle[MAX_PATH+1];
> +
> + GetStartupInfoW(&StartupInfo);
> +
> + if (StartupInfo.lpTitle)
> + {
> + /* Are we started from a shortcut? */
> + if (StartupInfo.dwFlags & 0x800)
> + {
> + UINT len;
> +
> + /* We are started from a shortcut, use the file name only */
> + lpFileName = wcsrchr(StartupInfo.lpTitle, '\\');
> + if (lpFileName == NULL)
> + {
> + lpFileName = StartupInfo.lpTitle;
> + }
> +
> + /* Drop file extension, we simply assume 3 chars extension */
> + len = wcslen(lpFileName) - 4;
> + if (len > 0)
> + {
> + len = min(len, MAX_PATH);
> + wcsncpy(szTitle, lpFileName, len);
> + szTitle[len] = 0;
> + SetConsoleTitleW(szTitle);
> + return;
> + }
> + }
> +
> + /* Use lpTitle member of STARTUPINFO */
> + SetConsoleTitleW(StartupInfo.lpTitle);
> + return;
> + }
> +
> + /* Set executable path as window title */
> + GetModuleFileNameW(NULL, szTitle, MAX_PATH);
> + SetConsoleTitleW(szTitle);
> + return;
> +}
> +
> +
> /*
> * set up global initializations and process parameters
> *
> @@ -1625,6 +1672,11 @@
> osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
> GetVersionEx (&osvi);
>
> + /* FIXME: Doesn't work in ros yet, because of missing functionality of ShellExecute.
> + See bug 2743. Please unif as soon as it get's fixed. */
> +#if 0
> + InitTitle();
> +#endif
> /* Some people like to run ReactOS cmd.exe on Win98, it helps in the
> * build process. So don't link implicitly against ntdll.dll, load it
> * dynamically instead */
>
>
Hello,
Hervé added some Standard C library headers to the "include/crt" directory
in r29178.
Now some people noticed that these changes broke building ReactOS components
with MSVC using the ReactOS headers ("Debug - ReactOS headers" or "Release -
ReactOS headers" configuration).
I have some general doubts about these changes.
>From my knowledge, the headers added in this commit, are compiler-specific
and target-independent. You can easily see that they are specific to
GCC/mingw as for example "stdio.h" includes a "_mingw.h" file with
mingw-specific stuff.
"stdarg.h" even leads to compilation problems with non-GCC-compilers (like
MSVC), because it defines a type based on the __builtin_va_list type, and
this built-in type only exists for GCC.
In my opinion, this commit should be reverted.
This way every compiler will use its own Standard C library headers and MSVC
should be able to build ReactOS components using the ReactOS Win32 headers
again.
Regards,
Colin
Hi All!
(subsystems\win32\win32k\ntuser\windc.c:156) FREE DCATTR!!!! NOT DCE_WINDOW_DC!!!!! hDC-> 6010078
(subsystems\win32\win32k\objects\dc.c:2549) DC_FreeDC DC_ATTR 0x2d80000
(subsystems\win32\win32k\ntuser\windc.c:551) ENTER!!!!!! DCX_CACHE!!!!!! hDC-> 6010078
(subsystems\win32\win32k\ntuser\windc.c:272) Exit!!!!! DCX_CACHE!!!!!! hDC-> 6010078
(subsystems\win32\win32k\objects\dc.c:2549) DC_FreeDC DC_ATTR 0x1020000
(subsystems\win32\win32k\ntuser\windc.c:156) FREE DCATTR!!!! NOT DCE_WINDOW_DC!!!!! hDC-> 14010092
(subsystems\win32\win32k\objects\dc.c:2549) DC_FreeDC DC_ATTR 0x1030000
(subsystems\win32\win32k\ntuser\windc.c:551) ENTER!!!!!! DCX_CACHE!!!!!! hDC-> 14010092
(subsystems\win32\win32k\ntuser\windc.c:272) Exit!!!!! DCX_CACHE!!!!!! hDC-> 14010092
(subsystems\win32\win32k\ntuser\windc.c:551) ENTER!!!!!! DCX_CACHE!!!!!! hDC-> 14010092
(subsystems\win32\win32k\ntuser\windc.c:272) Exit!!!!! DCX_CACHE!!!!!! hDC-> 14010092
Problem, Two Window DCE with DC objects are created and used through out the whole system and the
ownership was passed to NULL for both DC objects. The dcattr, allocated and ownership belongs to the
original process. So when testing the dcattr in user mode, creates user exception faults.
DC object one: 6010078 and object two: 14010092.
The Fix:
First, I free the "non owned window (DCX_CACHE) DCE DC" dcattr before the DC is placed in
"inaccessible mode" so the ownership of the dcattr is not lost. All traces of ownership comes from
the DC handle information. Once it is set NULL it is lost.
Second, I display the "Enter" (GetDCx) and "Exit" (ReleaseDC) for non owned window DCE DC. I'm doing
this so I can trace it out.
and,,,....
For DCX_CACHE DCE: ENTER "Get" allocate a new dcattr for the current process. EXIT "Release" free
the dcattr for that process. Windows does something similar to this.
Here is the patches,,, The test is: click on the time clock at the bottom right. Click on adjust
time and date. There you go.... the Gdi patch allows access to the dcattr pen for the DCE DC now.
It works,,,,, Thanks, James
subsystems/win32/win32k:
Index: ntuser/windc.c
===================================================================
--- ntuser/windc.c (revision 29544)
+++ ntuser/windc.c (working copy)
@@ -153,6 +153,8 @@
}
else
{
+ DPRINT1("FREE DCATTR!!!! NOT DCE_WINDOW_DC!!!!! hDC-> %x\n", pDce->hDC);
+ DC_FreeDcAttr(pDce->hDC, NULL); // Free the dcattr!
DC_SetOwnership(pDce->hDC, NULL); // This hDC is inaccessible!
}
@@ -267,6 +269,9 @@
dce->DCXFlags |= DCX_DCEEMPTY;
}
}
+ DPRINT1("Exit!!!!! DCX_CACHE!!!!!! hDC-> %x \n", dce->hDC);
+ DC_FreeDcAttr(dce->hDC, NULL); // Free the dcattr!
+ DC_SetOwnership(dce->hDC, NULL);
}
return 1;
}
@@ -543,6 +548,14 @@
DceUpdateVisRgn(Dce, Window, Flags);
}
+ if (Dce->DCXFlags & DCX_CACHE)
+ {
+ DPRINT1("ENTER!!!!!! DCX_CACHE!!!!!! hDC-> %x\n", Dce->hDC);
+ DC_SetOwnership( Dce->hDC, PsGetCurrentProcess());
+ DC_AllocateDcAttr( Dce->hDC, NULL);
+ DCU_SynchDcAttrtoUser( Dce->hDC, -1); // Copy data from dc to dcattr
+// Dce->pProcess = PsGetCurrentProcess();
+ }
return(Dce->hDC);
}
dll/win32/gdi32:
Index: dc.c
===================================================================
--- dc.c (revision 29544)
+++ dc.c (working copy)
@@ -320,7 +320,7 @@
STDCALL
GetDCObject( HDC hDC, INT iType)
{
-#if 0
+//#if 0
if((iType == GDI_OBJECT_TYPE_BRUSH) ||
(iType == GDI_OBJECT_TYPE_EXTPEN)||
(iType == GDI_OBJECT_TYPE_PEN) ||
@@ -348,7 +348,7 @@
}
return hGO;
}
-#endif
+//#endif
return NtGdiGetDCObject( hDC, iType );
}
Hi,
what I can tell right away, is that it's a very interesting, suitable
for diploma thesis work, but it's a challenge. You should posses
general knowledge about operating systems development, and more
specific knowledge about NT-based kernels, L4, and Linux.
The only problem may be
> I am not very experienced in C or assembler programming but am
> motivated to learn. But before i start working on that topic i have
but that could be compensated by outstanding OS dev skills /
architecture knowledge.
From the side of ReactOS Development Team, I'm sure you will have
support in terms of either visiting the irc-channel #reactos on
freenode or asking questions in this mailing list.
WBR,
Aleksey Bragin.
On Oct 10, 2007, at 3:08 PM, Henning Schild wrote:
> Hi there,
>
> i am thinking of porting ros to the L4 micro-kernel as topic for my
> diploma thesis. The operating systems group in Dresden already ported
> Linux to L4 (http://os.inf.tu-dresden.de/L4/LinuxOnL4/) and proofed
> that L4 offers all that is needed to run an operating system in
> userspace on top of it.
>
> The goal of the work would be to be able to run windows applications
> next to miro-kernel applications. And to compare the performance with
> that of pure ros, L4Linux/wine and windows. A comparison between the
> port and L4Linux could also be part of the work. (mapping processes to
> L4 tasks, memory management, interrupt-handling and so on)
>
> I am not very experienced in C or assembler programming but am
> motivated to learn. But before i start working on that topic i have
> some questions on the portability of ros.
>
> In svn and on the ros website i found that there is a ppc port of ros.
> And on irc someone told me that there is ongoing work on a ros
> usermode
> port. I also read about a xen port. But i did not yet find working
> copies of the any of that ports. I built ros for i386 on my
> machine and was able to boot it in vmware. I also tried building the
> latest svn version with ROS_ARCH=powerpc but that did not succeed.
>
> 1. Did anyone ever finish a port to another arch?
> 2. How portable is ros in general? Meaning how much code would have to
> be changed. I hope there are abstractions and only 10-15% of the
> kernel
> would have to be changed.
> 3. Do you believe that one person new to ros can finish that kind of
> work in 6 months? I know that might be hard to answer but how long did
> any of you need to learn ros in detail?
> 4. If there are working ports, how long did it take to implement
> them?
> If there are not, what are the reasons they where never finished? I am
> thinking of lots of assembler and i386 hacks.
>
> 5. Finally, what do think of the idea itself?
>
> I hope you take the time to answer my questions. I am still on the way
> to determine whether i really want to do that and whether i can do
> this
> in 6 months.
>
> regards,
> Henning Schild