When I try to link advapi32 with two widl-generated files (scm_client
and eventlog_client) I get conflict:
[LD] output-i386\lib\advapi32\advapi32.dll
obj-i386\include\idl\svcctl_c.o: In function `ScmrCloseServiceHandle':
D:/trunk/reactos/obj-i386/include/idl/svcctl_c.c:87: multiple definition
of `__MIDL_ProcFormatString'
obj-i386\include\idl\eventlogrpc_c.o:D:/trunk/reactos/obj-i386/include/idl/eventlogrpc_c.c:87:
first defined here
obj-i386\include\idl\svcctl_c.o: In function `ScmrLockServiceDatabase':
D:/trunk/reactos/obj-i386/include/idl/svcctl_c.c:245: multiple
definition of `__MIDL_TypeFormatString'
obj-i386\include\idl\eventlogrpc_c.o:D:/trunk/reactos/obj-i386/include/idl/eventlogrpc_c.c:182:
first defined here
collect2: ld returned 1 exit status
make: *** [output-i386\lib\advapi32\advapi32.dll] Error 1
How to solve this?
> From: ekohl(a)svn.reactos.org
>
> - Service list entries use a pointer to a group list entry
> instead of the goup name.
> - New group list entries are created in the
> unknown-group-list for services of unknown groups.
I'm seeing some crashes now because the lpGroup->lpService pointer is NULL.
Patch below seems to fix it, but I have no idea if it's the correct fix.
GvG
Index: subsys/system/services/rpcserver.c
===================================================================
--- subsys/system/services/rpcserver.c (revision 20508)
+++ subsys/system/services/rpcserver.c (working copy)
@@ -927,7 +927,7 @@
if (lpdwTagId != NULL)
{
- dwError = ScmAssignNewTag(lpService->lpGroup->lpGroupName,
+ dwError = ScmAssignNewTag(lpLoadOrderGroup,
&lpService->dwTag);
if (dwError != ERROR_SUCCESS)
goto done;
@@ -1161,7 +1161,7 @@
if (lpdwTagId != NULL)
{
- dwError = ScmAssignNewTag(lpService->lpGroup->lpGroupName,
+ dwError = ScmAssignNewTag(lpLoadOrderGroup,
&lpService->dwTag);
if (dwError != ERROR_SUCCESS)
goto done;
Sunday night I will remove the svn.reactos.com DNS entry, please use
svn.reactos.org in the future. If you currently have a working copy checked
out from svn://svn.reactos.com you can tell svn to use svn.reactos.org in
the future by:
> From: WaxDragon
>
> Say you have a checkout in ~/src/reactos that was originally checked
> out from svn://svn.reactos.com/trunk/reactos. from the root of the
> checkout (~src/reactos) issue:
>
> svn switch --relocate svn://svn.reactos.com/trunk/reactossvn://svn.reactos.org/trunk/reactos
If you're using Tortoise:
> From: Maarten Bosma
>
> Just right click in root dir, chosse "TortiseSVN > Relocate..." and then
> enter svn://svn.reactos.org/trunk/reactos into the dialog.
Or if you have no local changes you could just delete your working copy and
check out a new one from reactos.org.
If you insist on using svn.reactos.com, add a line "213.173.252.2
svn.reactos.com" to your hosts file (/etc/hosts for Linux/Unix,
%SystemRoot%\System32\drivers\etc\hosts on Windows).
Gé van Geldorp.
gedmurphy(a)svn.reactos.org wrote:
> + CONTROL "Automatically synchronize with an Internet time server", IDC_AUTODAYLIGHT,
> + "Button", BS_AUTOCHECKBOX | WS_GROUP | WS_TABSTOP,11,7,241,10
>
oops, ignore the IDC_AUTODAYLIGHT typo, I'll fix it when I get round to
putting the rest of the code in :)
Ged.
Does anyone mind if I import libjpeg for jpg support ? The License is
not a problem, but the patent might be. Sorry that ask so late (did
already a vendor import). I asked 2 times on IRC and thought that would
be enough, but GreatLord convinced me that I have to asked here too.
Maarten Bosma
PS: The size of the files that would go into reactos/lib is 694 KB.
A while ago, when it was mentioned that ROS 2.9 is soon to be released I
proposed to put out a VMWare image of it - never got a reply though, or
missed it. It has been mentioned multiple times that VMWare is used by some
ROS-devs, so this shouldn't be a problem in the first place.
Since the authors of VMWare have released a so-called VMWare-Player (see
http://www.vmware.com/products/player/ ), it is easy for anyone to get both
(given that they don't have VMWare, yet). VMWare is certainly faster than
QEMU or Bochs for several reasons and thus would be a better "experience"
for potential ROS testers and users.
And please don't tell me that is a kind of endorsement of VMWare, since the
link on the website already is. There is at least one (much cheaper)
alternative to VPC and VMWAre, called Parallels which is not mentioned on
the website at all ( http://www.parallels.com/en/products/workstation/ ).
I just wanted to remind all of you of this idea for (re)consideration.
Cheers,
Oliver
Hi,
I've fixed Alex' win32k changes. First, I try to commit the original
changes. I've used 'svn merge -r20366:20368
svn://svn.reactos.org/trunk/reactos' to get the changes and I'm using
'svn commit' to commit the changes again. I get an error message:
I:\Sandbox\ros_work\reactos>svn commit
Lösche include\win32k\bitmaps.h
<snip>
Sende w32api\include\wingdi.h
Übertrage Daten ................svn: Übertragen fehlgeschlagen (Details
folgen):
svn: Source url
'svn://svn.reactos.org/trunk/reactos/include/win32k/ntgdibad.h' is from
different repository
svn: Ihre Log-Meldung wurde in einer Temporärdatei abgelegt:
svn: 'I:/Sandbox/ros_work/reactos/svn-commit.2.tmp'
Usually, I get all error messages in german. What do I make wrong?
- Hartmut
ion(a)svn.reactos.org wrote:
> + /* Value changed... wait until it's locked */
> + while (*SpinLock == 1) YieldProcessor();
This might be optimized away since SpinLock was not defined as volatile
KSPIN_LOCK*
- Thomas
greatlrd(a)svn.reactos.org wrote:
> some case from win32k can call to RtlClearAllBits with NULL pointer. and check for null pointer after RtlClearAllBits. This take care of those case for moment.
This change is wrong, please revert it and fix win32k instead.
- Thomas
ion(a)svn.reactos.com wrote:
> - Also made the boot-up screen black, not blue, since that's the actual color it's been after NT4. If booting without NOGUIBOOT, this results in a much nicer transition to the boot screen (especially if using the NTLDR theme)
>
This changes the 'blue screen of death' to a 'black screen of death'. I
don't like it if you change every and any thing to the real windows
implementation. I see no reason for this cloning.
- Hartmut
Why was this done? Having these bugs listed as blockers to 399 allows
devs to find the old bugs easier in case of regressions. I don't see
any downsize to keeping them listed.
On 12/28/05, ReactOS.Bugzilla(a)reactos.org <ReactOS.Bugzilla(a)reactos.org> wrote:
> http://www.reactos.org/bugzilla/show_bug.cgi?id=399
>
>
> greatlord(a)reactos.com changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> BugsThisDependsOn|398, 400, 937 |
>
>
>
>
> ------- Additional Comments From greatlord(a)reactos.com 2005-12-28 17:54 CET -------
> Bug 398 are fixed, Bug 400 are fixed, Bug 937 are fixed
> I remove tuse from Bug depends on.
>
>
>
> --
> Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
> You are the QA contact for the bug, or are watching the QA contact.
> _______________________________________________
> Ros-bugs mailing list
> Ros-bugs(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-bugs
>
WD
--
<Russell> argh
<Russell> iterator shenanigans :/
ion(a)svn.reactos.com wrote:
> - Major Win32k Header Cleanup: Add ntgdi.h based on latest Platform SDK Public header. It contains the official definitions for NtGdi APIs.
> - Added ntgdityps.h for structures needed to use the header (which were sadly not publically shipped).
> - Removed internal win32k header data from public headers and put it to internal win32k headers.
> - Fixed ntuser.h STDCALL->WINAPI.
> - Added ntgdihdl.h for shared GDI Handle information between gdi32/win32k
> - Added ntusrtyp.h for some shared NtUser types.
> - Added ntgdibad.h which contains all non-compatible NtGdi prototypes, along with a detailed comment for each, and information on how to fix it. I had a 20 000+ line patch fixing all these issues, but it contained many bugs and I scrapped it in place for this approach, which while dirtier at first, simplifies the number of changes needed so that others can work on it as well.
> - Fixed some gdi32/win32k/user32 header issues.
>
>
This change breaks running ros on qemu and real hardware. I don't see a
mouse cursor after the gui is started. If I move the mouse, ros does
crash. If I don't move the mouse, ros starts up to the first device
install dialog. After this ros terminates itself and does switch off the
computer.
- Hartmut
(ntoskrnl\mm\mm.c:317) Address: 87dcf974
Unhandled exception
ExceptionCode: c0000005
Faulting Address: 87dcf974
Address: 77e9238b C:\ReactOS\system32\user32.dll
CS:EIP 1b:77e9238b
DS 23 ES 23 FS 3b GS 0
EAX: 87dcf974 EBX: 0144fdec ECX: 0144ffb4
EDX: f000ff53 EBP: 0144fb6c ESI: 00000000 ESP: 0144fb24
EDI: 00000000 EFLAGS: 00000246
Frames:
77e50000+2f461 C:\ReactOS\system32\user32.dll
77e50000+2fdf6 C:\ReactOS\system32\user32.dll
77e50000+31fb6 C:\ReactOS\system32\user32.dll
10000000+72cf C:\ReactOS\system32\win32csr.dll
77e50000+52657 C:\ReactOS\system32\user32.dll
77e50000+53a52 C:\ReactOS\system32\user32.dll
7c900000+a15b C:\ReactOS\system32\ntdll.dll
10000000+764e C:\ReactOS\system32\win32csr.dll
7c800000+2fe1d C:\ReactOS\system32\kernel32.dll
(./subsys/win32k/ntuser/window.c:581) thread cleanup: while destroy
wnds, wnd=0x870d11a4
(subsys\win32k\main\dllmain.c:281) thread clean: remove reference obj
0x870d11a4
(subsys\win32k\main\dllmain.c:281) thread clean: remove reference obj
0x870d11a4
KeBugCheckWithTf at ntoskrnl\ke\i386\exp.c:1242
A problem has been detected and ReactOS has been shut down to prevent
damage to your computer.
The problem seems to be caused by the following file: win32k.sys
Technical information:
*** STOP: 0x0000001E (0xc0000005,0x9da2ba1f,0x00000000,0xfffffff4)
*** win32k.sys - Address 0x9da2ba1f base at 0x9d99b000, DateStamp 0x0
Page Fault Exception: 14(0)
Processor: 0 CS:EIP 8:9da2ba1f <win32k.sys:90a1f
(./subsys/win32k/ntuser/msgqueue.c:271 (co_MsqTranslateMouseMessage))>
cr2 fffffff4 cr3 f58c000 Proc: 80ac2050 Pid: 7c <csrss.exe> Thrd:
80c6d220 Tid: b4
DS 23 ES 23 FS 30 GS 0
EAX: fffffff4 EBX: 80c6d5f8 ECX: 00000000
EDX: 9da883d0 EBP: 9e194a8c ESI: 0164fe24 ESP: 9e1949f0
EDI: 9e194d64 EFLAGS: 00000297 kESP 9e1949f0 kernel stack base 9e192000
Frames:
<win32k.sys:9170b (./subsys/win32k/ntuser/msgqueue.c:621
(co_MsqPeekHardwareMessage))>
<win32k.sys:92bfa (./subsys/win32k/ntuser/msgqueue.c:1259
(co_MsqFindMessage))>
<win32k.sys:88626 (./subsys/win32k/ntuser/message.c:731
(co_IntPeekMessage))>
<win32k.sys:890a3 (./subsys/win32k/ntuser/message.c:941
(co_IntWaitMessage))>
<win32k.sys:893d2 (./subsys/win32k/ntuser/message.c:1051
(NtUserGetMessage))>
<ntoskrnl.exe:9a8ea (ntoskrnl\ke\i386\syscall.S:372 (KiSystemService))>
<user32.dll:52bd3 (lib/user32/windows/message.c:1166 (GetMessageW))>
>From the way ROS tends to hamng up when running CPU-intense processes,
I'm starting to suspect ROS is in fact not pre-emptively multitasking.
And this seems to have gotten worse from 0.2.8 to 0.2.9. Any thoughts?
/nitro2k01
--
The blog of nitro2k01: <http://soundandcomplete.blogspot.com/>
Saliga äro de som kan stava till 2k01!
hpoussin(a)svn.reactos.com wrote:
> Replace implementation of QueryServiceConfigW by a stub (like in pre-20255), as rpcrt4 throws sometimes an exception and breaks PnP manager
>
>
LOL!
That was no surprise! Sounds like Wine need to fix their broken code.
I had a patch but I'm still ban from sending email to wine-patch! So~
rm * the patch!
James
Hi,
I am pleased to announce that with Ge's patch to fix Exception
handling and Brandon and Thomas's work on the pagefile it is now
possible to install Office 2000 on the trunk. You will get quite a few
errrors at the end of the install due to missing dlls from MDAC/ADO
that Office2000 expects a Windows 2000 system to ship with, which we
of course do not have stubbed at this time. Thanks to Eric Kohls work
on services msiexec is mostly happy installing Office2000 if started
from the command line like the following
msiexec /i data1.msi
There is still issues with setup.exe properly working althogh I think
this is more due to version numbers we report.
We are still unable to run Office applications at this time due to
unhandled exceptions which look like they are due to COM errors as
well as some problems due to the amount of memory we are reporting.
Both Winword and Access display message boxes saying that there is not
enough memory to run the application. Also even if we do get those
issues fixed we are currently blocked by the registry instablity.
--
Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
ReactOS on LinuxTag 2006
From 3. till 6. May 2006 over 15000 guests will visit the LinuxTag in
Wiesbaden (Germany).
They provide free stands on the expo for open source projects.
I think ReactOS could be there too. Wiesbaden is not far from where I
live and if some of
the developers are interrested we could talk about making a stand.
Best Regards,
dom
I have found some problems running Allegro programs in ReactOS. When I
have tested it they started up and the mouse moves the upper right hand
corner of the screen and ReactOS apparently hangs. I'm curious why is
this happening; although, I think it is possibly some bugs (or bug) that
is causing it, or it is caused by an unimplemented feature. It is most
like located in the DirectX and OpenGL components. This realtes to bug
1112.
Merry Christmas!! :D
On 12/24/05, ros-dev-request(a)reactos.org <ros-dev-request(a)reactos.org> wrote:
> Send Ros-dev mailing list submissions to
> ros-dev(a)reactos.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.reactos.org/mailman/listinfo/ros-dev
> or, via email, send a message with subject or body 'help' to
> ros-dev-request(a)reactos.org
>
> You can reach the person managing the list at
> ros-dev-owner(a)reactos.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ros-dev digest..."
>
>
> Today's Topics:
>
> 1. Merry Christmas! (Filip Navara)
> 2. Re: Merry Christmas! (Rick Langschultz)
> 3. Re: Merry Christmas! (James Tabor)
> 4. Re: Merry Christmas! (Jerry)
> 5. Re: Merry Christmas! (Sebastian Gasiorek)
> 6. Re: Merry Christmas! (TwoTailedFox)
> 7. Merry Christmas (Magnus Olsen)
> 8. Re: Merry Christmas! (David Hinz)
> 9. Re: Merry Christmas! (Jonathon Keogh)
> 10. Re: PC offered with ReactOS preinstalled? (wac)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 24 Dec 2005 22:36:45 +0100
> From: Filip Navara <xnavara(a)volny.cz>
> Subject: [ros-dev] Merry Christmas!
> To: ReactOS Development List <ros-dev(a)reactos.org>
> Message-ID: <43ADBF6D.9020206(a)volny.cz>
> Content-Type: text/plain; charset=ISO-8859-2; format=flowed
>
> Hi all,
>
> I thought we can't break the tradion, so ... Merry Christmas and Happy
> New Year! :-)
>
> - Filip
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 24 Dec 2005 15:58:11 -0600
> From: Rick Langschultz <rlangschultz(a)cox.net>
> Subject: Re: [ros-dev] Merry Christmas!
> To: ReactOS Development List <ros-dev(a)reactos.org>
> Message-ID: <4912B7CF-9876-438A-A7D5-8F0E37ACAEFE(a)cox.net>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> Merry Christmas Filip ;-) and Happy New Year
> On Dec 24, 2005, at 3:36 PM, Filip Navara wrote:
>
> > Hi all,
> >
> > I thought we can't break the tradion, so ... Merry Christmas and
> > Happy New Year! :-)
> >
> > - Filip
> > _______________________________________________
> > Ros-dev mailing list
> > Ros-dev(a)reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 24 Dec 2005 22:07:21 +0000
> From: James Tabor <jimtabor(a)adsl-64-217-116-74.dsl.hstntx.swbell.net>
> Subject: Re: [ros-dev] Merry Christmas!
> To: ReactOS Development List <ros-dev(a)reactos.org>
> Message-ID:
> <43ADC699.5020803(a)adsl-64-217-116-74.dsl.hstntx.swbell.net>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> Filip Navara wrote:
> > Hi all,
> >
> > I thought we can't break the tradion, so ... Merry Christmas and Happy
> > New Year! :-)
> >
> > - Filip
> Yeah! Merry Christmas!
> 8^D
> James
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 24 Dec 2005 16:07:34 -0600
> From: Jerry <crashfourit(a)gmail.com>
> Subject: Re: [ros-dev] Merry Christmas!
> To: ReactOS Development List <ros-dev(a)reactos.org>
> Message-ID: <43ADC6A6.1040503(a)gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Merry Christmas, Rick, Filip and all those who will read this.
> Rick Langschultz wrote:
>
> > Merry Christmas Filip ;-) and Happy New Year
> > On Dec 24, 2005, at 3:36 PM, Filip Navara wrote:
> >
> >> Hi all,
> >>
> >> I thought we can't break the tradion, so ... Merry Christmas and
> >> Happy New Year! :-)
> >>
> >> - Filip
> >> _______________________________________________
> >> Ros-dev mailing list
> >> Ros-dev(a)reactos.org
> >> http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> > _______________________________________________
> > Ros-dev mailing list
> > Ros-dev(a)reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
>
>
>
> ------------------------------
>
> Message: 5
> Date: Sat, 24 Dec 2005 23:12:23 +0100
> From: Sebastian Gasiorek <zebasoftis(a)gmail.com>
> Subject: Re: [ros-dev] Merry Christmas!
> To: ReactOS Development List <ros-dev(a)reactos.org>
> Message-ID: <77c53c6f0512241412m1644d008n(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Merry Christmas
> and
> Happy New Year to everybody :-)
>
>
> 2005/12/24, Rick Langschultz <rlangschultz(a)cox.net>:
> >
> > Merry Christmas Filip ;-) and Happy New Year
> > On Dec 24, 2005, at 3:36 PM, Filip Navara wrote:
> >
> > > Hi all,
> > >
> > > I thought we can't break the tradion, so ... Merry Christmas and
> > > Happy New Year! :-)
> > >
> > > - Filip
> > > _______________________________________________
> > > Ros-dev mailing list
> > > Ros-dev(a)reactos.org
> > > http://www.reactos.org/mailman/listinfo/ros-dev
> >
> > _______________________________________________
> > Ros-dev mailing list
> > Ros-dev(a)reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
> >
>
My Spanish is not that great, but I get the impression that they're offering
PCs with ReactOS preinstalled here:
http://articulo.mercadolibre.com.mx/MLM-10172918--_JM Can anyone confirm
that? Not that I mind, I'm just curious.
Gé van Geldorp.
Hi
I bit sick of correct it hold time for make a rc compile with ms vs
to right one.
Here is the rule to use it
Rule for SUBLANG_DEFAULT
Basic all langues only have one offcial langues must use SUBLANG_DEFAULT
example Czech, Danish, Hungarian, Polish and more.
Rule for SUBLANG_NEUTRAL
basic all langues only have more one offcial langues must use SUBLANG_NEUTRAL
example German, French, English, Swedish, and more
please think of this when you are writen or change .rc file.
Thanks