On Wednesday 30 November 2005 18:19, Alex Buell wrote:
> Looks like I'll be filing a bug report with Gentoo to get them to bump
> their xmingw binutils to 2.15.94 - it's 2.15.90.0.2 at the moment.
> Thanks.
* dev-util/xmingw-binutils
Latest version available: 2.15.94.20050118.1
Latest version installed: 2.15.94.20050118.1
Just unmask it....
Hey Hey,
Just wanted to give a heads up to the community about the following
error on my iBook g4. There was USB enabled when i installed then I
removed it. I was wondering if there is being a rewrite of this or
something. Plus I can't submit a bugzilla report because of site
restrictions.
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
KMODE_EXCEPTION_NOT_HANDLED
Technical information:
*** STOP: 0x0000001E (0xc0000005,0x9d929c33,0x00000000,0x00000004)
*** win32k.sys - Address 0x9d929c33 base at 0x9d872000, DateStamp 0x0
Page Fault Exception: 14(0)
Processor: 0 CS:EIP 8:9d929c33 <win32k.sys:b7c33 (./subsys/win32k/
objects/dc.c:5
76 (IntPrepareDriver))>
cr2 4 cr3 e5ce000 Proc: 80dc9670 Pid: ec <umpnpmgr.exe> Thrd:
80e160a0 Tid: f8
DS 23 ES 23 FS 30 GS 0
EAX: 00000000 EBX: 9d92ad56 ECX: 00000000
EDX: 00000000 EBP: 9e29eb5c ESI: 00cef564 ESP: 9e29ea70
EDI: 9e29ed64 EFLAGS: 00000202 kESP 9e29ea70 kernel stack base
9e29c000
Frames:
<win32k.sys:b7e71 (./subsys/win32k/objects/dc.c:661
(IntPrepareDriverIfNeeded))>
<win32k.sys:b85ba (./subsys/win32k/objects/dc.c:838 (IntGdiCreateDC))>
<win32k.sys:b900b (./subsys/win32k/objects/dc.c:1051 (NtGdiCreateIC))>
<ntoskrnl.exe:9a4ea (ntoskrnl\ke\i386\syscall.S:372 (KiSystemService))>
<gdi32.dll:8761 (lib/gdi32/objects/dc.c:128 (CreateICW))>
I get the following error, when I try to compile revision 19777:
[CC] lib\devmgr\advprop.c
lib\devmgr\advprop.c: In function `DisplayDeviceAdvancedProperties':
lib\devmgr\advprop.c:247: error: `DIGCDP_FLAG_REMOTE_ADVANCED'
undeclared (first use in this function)
lib\devmgr\advprop.c:247: error: (Each undeclared identifier is reported
only once
lib\devmgr\advprop.c:247: error: for each function it appears in.)
mingw32-make: *** [obj-i386\lib\devmgr\advprop.o] Error 1
If I remember right, the last working revision was 19776, but I don't
know exactly.
Anyway, the files changed since my last successfull compilation are:
U lib\devmgr\devmgr.xml
U lib\devmgr\En.rc
U lib\devmgr\precomp.h
U lib\devmgr\advprop.c
U lib\devmgr\hwpage.c
U lib\devmgr\misc.c
U lib\devmgr\resource.h
Hope you get that fixed soon.
Greets,
David Hinz
LOL !!!
Check your mail headers and you'll see the unsubscribe address.
Or you can be lazy and click on the following link ;)
mailto:ros-dev-request@reactos.org?subject=unsubscribe
-----Original Message-----
From: frank.marx(a)t-online.de [mailto:frank.marx@t-online.de]
Sent: 30 November 2005 11:51
To: ReactOS Development List
Subject: Re: [ros-dev] [Fwd: [ros-svn] CC: Eric/IDL Guys - MIDL
Compatibility]
Importance: Low
Please DONT send me further emails !
Thank you !
Frank Marx
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
************************************************************************
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
Hello Alex
No, it wasnt commited yet. The best way to submit patches is through
bugzilla under the patch group. http://www.reactos.org/bugzilla/
Brandon
Alex Buell wrote:
> obj-i386/lib/rtl/rtl.a(math_asm.o)(.text+0x50e):lib/rtl/i386/math_asm.S:1439:
> undefined reference to `not'
> obj-i386/lib/rtl/rtl.a(math_asm.o)(.text+0x529):lib/rtl/i386/math_asm.S:1451:
> undefined reference to `not'
> obj-i386/lib/rtl/rtl.a(math_asm.o)(.text+0x54f):lib/rtl/i386/math_asm.S:1467:
> undefined reference to `not'
> collect2: ld returned 1 exit status
> make[1]: *** [output-i386/lib/ntdll/ntdll.dll] Error 1
>
> Why hasn't my patch gone in yet? If not, why not?
>
I have recently been reviewing the DosEmu thread on the list. Here is
my concern, why not try doing something like XEN for reactos. CMD.exe
could interact with all of the XENed hardware and software. One major
feature this would be great for is if someone needed to utilize a
EXT3 disk image or hard drive from ReactOS in the future all they
would have to do is pop open the cmd prompt and cd to a virtual hard
drisk something like C:\Volumes\HDA1\ would be equal to / on the
linux volume. A system service would also need to be implemented for
starting the other os on command, but that is only a suggestion...
Rick
cwittich(a)svn.reactos.com wrote:
>added more correct linker flags (patch by brezenbak)
>
>Modified: trunk/reactos/tools/rbuild/backend/msvc/vcprojmaker.cpp
>
>
> ------------------------------------------------------------------------
> *Modified: trunk/reactos/tools/rbuild/backend/msvc/vcprojmaker.cpp*
>
>--- trunk/reactos/tools/rbuild/backend/msvc/vcprojmaker.cpp 2005-11-30 00:25:48 UTC (rev 19764)
>+++ trunk/reactos/tools/rbuild/backend/msvc/vcprojmaker.cpp 2005-11-30 00:26:51 UTC (rev 19765)
>@@ -330,8 +330,17 @@
>
> }
> else if ( exe )
> {
>
>
>- fprintf ( OUT, "\t\t\t\tSubSystem=\"%d\"\r\n", console ? 1 : 2 );
>- fprintf ( OUT, "\t\t\t\tBaseAddress=\"%s\"\r\n", module.baseaddress.c_str ());
>
>
>+ if ( module.type == Kernel || module.type == NativeCUI)
>+ {
>+ fprintf ( OUT, "\t\t\t\tAdditionalOptions=\" /SUBSYSTEM:NATIVE /SECTION:INIT,D /ALIGN:4096 /FORCE:MULTIPLE\"\r\n" );
>+ fprintf ( OUT, "\t\t\t\tIgnoreAllDefaultLibraries=\"TRUE\"\r\n" );
>+ fprintf ( OUT, "\t\t\t\tEntryPointSymbol=\"%s\"\r\n", module.entrypoint.c_str ());
>+ fprintf ( OUT, "\t\t\t\tBaseAddress=\"%s\"\r\n", module.baseaddress.c_str ());
>+ }
>+ else if ( module.type == Win32CUI || module.type == Win32GUI )
>+ {
>+ fprintf ( OUT, "\t\t\t\tSubSystem=\"%d\"\r\n", console ? 1 : 2 );
>+ }
>
>
> }
> else if ( dll)
> {
>
>
This still isn't fully correct.
First, the check should be widened to inculde Drivers.
Secondly, /SECTION:INIT,D should only be used for Kernel or Drivers, not
Native apps. Thirdly, /ALIGN:4096 is irrelevant -- this is the default.
Kernel should get 0x80, and drivers should get 0x20.
Fourthly, Kernel entrypoint should be hard-coded to KiSystemStartup,
while Native apps shoudl be hardcoded to NtProcessStartup. This is
especially important so that nt.lib will get used properly.
Also, NativeCUI is a bit repetitive. Native can only be CUI.
Drivers should also be compiled with /DRIVER.
Native, Kernel and Drivers should have /NODEFAULTLIB.
/FORCE:MULTIPLE is ugly and I don't know why it was added.
Best regards,
Alex Ionescu
Hi,
looking through our file functions, we do always access a file object
after it was dereferenced by the completion routine and if the
FO_SYNCHRONOUS_IO flag is set. If FO_SYNCHRONOUS_IO is set, the
completion routine should not dereference the file object or we have to
add an additional reference. If FO_SYNCHRONOUS_IO is set, we have also
to dereference the file object after calling the driver.
- Hartmut