Hi ARMs,
Doing a good job BTW~
Thanks,
James
(ntoskrnl/kd/kdio.c:191) -----------------------------------------------------
(ntoskrnl/kd/kdio.c:192) ReactOS 0.4-SVN (Build 20080728-r34871)
(ntoskrnl/kd/kdio.c:193) Command Line: DEBUG DEBUGPORT=COM1
BUADRATE=115200 SOS
(ntoskrnl/kd/kdio.c:194) ARC Paths:
multi(0)disk(0)rdisk(0)partition(1) \ multi(0)disk(0)rdisk(0)parti
tion(1) \ReactOS\
Used memory 1015348Kb
(ntoskrnl/mm/mminit.c:295) Start End Type
(ntoskrnl/mm/mminit.c:296) 0x80000000 - 0x80800000 Undefined region
(ntoskrnl/mm/mminit.c:299) 0x80800000 - 0x80E00000 FreeLDR Kernel
mapping region
(ntoskrnl/mm/mminit.c:302) 0x80E00000 - 0x815C0000 PFN Database region
(ntoskrnl/mm/mminit.c:309) 0x815C0000 - 0x879C0000 Non paged pool region
(ntoskrnl/mm/mminit.c:312) 0x879C0000 - 0x8DDC0000 Paged pool region
(ntoskrnl/ke/i386/kiinit.c:47) Large Page support detected but not yet
taken advantage of!
WARNING: KdDebuggerInitialize1 at drivers/base/kdcom/i386/kdbg.c:489
is UNIMPLEMENTED!
WARNING: IoReportResourceUsage at ntoskrnl/io/iomgr/iorsrce.c:700 is
UNIMPLEMENTED!
WARNING: IoReportResourceUsage at ntoskrnl/io/iomgr/iorsrce.c:700 is
UNIMPLEMENTED!
(ntoskrnl/io/iomgr/driver.c:1356) '\Driver\BUSLOGIC' initialization
failed, status (0xc00000c0)
(ntoskrnl/io/iomgr/driver.c:1356) '\Driver\Floppy' initialization
failed, status (0xc000000e)
Assertion 'KeGetCurrentIrql()<=(1)' failed at ntoskrnl/ke/gmutex.c line 201
Entered debugger on embedded INT3 at 0x0008:0x808a8262.
kdb:> bt
Eip:
<NTOSKRNL.EXE:a8263 (lib/rtl/i386/debug_asm.S:33 (DbgBreakPoint@0))>
Frames:
<NTOSKRNL.EXE:a027 (ntoskrnl/ke/gmutex.c:201 (@KeAcquireGuardedMutex@4))>
<NTOSKRNL.EXE:6d3a2 (ntoskrnl/include/internal/mm.h:1556
(MmProbeAndLockPages@12))>
<NTOSKRNL.EXE:4f079 (ntoskrnl/io/iomgr/irp.c:694
(IoBuildAsynchronousFsdRequest@24))>
<SCSIPORT.SYS:4671 (drivers/storage/scsiport/scsiport.c:3959
(ScsiPortDpcForIsr@16))>
<NTOSKRNL.EXE:823a (ntoskrnl/ke/dpc.c:474 (@KiRetireDpcList@4))>
<NTOSKRNL.EXE:9fc59 (ntoskrnl/ke/i386/ctxswitch.S:691 (@KiIdleLoop@0))>
<00000000>
kdb:>
Hi,
I've been attempting to sync some of the Wine dlls, namely the IE
support dlls and have run in to a bit of a problem which I think is a
bug in ReactOS widl. It seems that the import keyword is not working.
When trying to build shdocvw.dll it creates a shdocvw_v1.tlb based on
shdocvw_v1.idl which imports exdisp.idl from the SDK which in turn
does an import ("stdole2.tlb")
As you can see from the output below
sedwards@mini-gimli:~/source/reactos$ make shdocvw
[WIDL] obj-i386/dll/win32/shdocvw/shdocvw_v1.tlb
error: Could not open importlib stdole2.tlb.
mingw32-make: *** [obj-i386/dll/win32/shdocvw/shdocvw_v1.tlb] Error 2
Total Build Time: 00:00:02
Notice the . at the end of stdole2.tlb? I've tried just renaming the
typelib and putting it in several intermediate folders to no effect.
If any WIDL Guru can help please find the attached patch which
contains an updated shdocvw.rbuild
Thanks
Steven
--
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
Yesterday I was playing around with the test suite in HEAD when I moved onto
kernel32.
It was, without wanting to sound too harsh, a bit of a disgrace, with large
failures throughout the whole test range.
I suggest a hacking day on it using the test suite, a joint effort to bring
this core lib back into line. Perhaps with some emphasis on trying to make
it fun.
Whoever gets the most fixes is crowned 'king ding-a-ling' and holds the
title until the next one, opening the road up to days on ntdll, user32,
gdi32 and crt?
Ged.
Hi,
When installing Java or anything with java it hangs and just sit there
running. It could be OOo 2.4 or installing java, does not mater, I
just left the box running all night and just sits there, still
installing..
This bug fault right after I restarted. Is it waiting on a lock?
Assertion 'WaitBlock->Signaled' failed at ntoskrnl/ex/pushlock.c line 599
Entered debugger on embedded INT3 at 0x0008:0x808ad242.
kdb:> bt
Eip:
<NTOSKRNL.EXE:ad243 (lib/rtl/i386/debug_asm.S:33 (DbgBreakPoint@0))>
Frames:
<NTOSKRNL.EXE:2da24 (ntoskrnl/ex/pushlock.c:599
(@ExfAcquirePushLockExclusive@4))>
<NTOSKRNL.EXE:6eb00 (ntoskrnl/include/internal/ex.h:715
(MiProtectVirtualMemory@20))>
<NTOSKRNL.EXE:6fdbf (ntoskrnl/mm/virtual.c:927 (NtProtectVirtualMemory@20))>
<NTOSKRNL.EXE:979ca (ntoskrnl/ke/i386/trap.s:244 (KiFastCallEntry))>
<ntdll.dll:5e1a> ntdll/main/i386/dispatch.S:297 (KiFastSystemCallRet@0)
<kernel32.dll:e0ce> kernel32/mem/virtual.c:127 (VirtualProtect@16)
<jvm.dll:149b27>
kdb:>
Hi all,
I'm working on first stage gui setup.
During the development i reviewed the base/setup directory and the different
modules. I suggest following changes:
Now:
reactos.exe: atm greeting only with disabled first stage setup dialogs
setup.exe: switcher for 2nd stage setup (syssetup) or livecd
usetup.exe: textmode 1st stage setup
vmwinst.exe: don't know exactly, vm-ware driver installation
welcome.exe: nice welcome dialog without real functions
Future:
setup.exe: switcher for 1st stage gui setup, 2nd stage setup, livecd and
welcome dialog switched by command line arguments
"setup.exe" -> welcome dialog
"setup.exe -mini" -> livecd
"setup.exe -newsetup1" -> 1st stage gui setup
"setup.exe -newsetup2" -> 2nd stage (gui) setup
usetup.exe: textmode 1st-stage-setup
vmwinst.exe: keeps unchangend
reactos.exe, welcome.exe: removed
Are there any objections to go this way? If not, so i will change this soon.
Matthias
--
Matthias Kupfer Telefon +49 (0) 371 236 46 52
Wilhelm-Firl-Straße 21 Mobil +49 (0) 160 859 43 54
09122 Chemnitz
On Tue, Jul 22, 2008 at 9:56 AM, Sylvain Petreolle <spetreolle(a)yahoo.fr> wrote:
> It'sToo bad the header is not in an include directory...
Maybe it should go in the NDK then.
--
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
> De : Steven Edwards <winehacker(a)gmail.com>
> À : ros-dev(a)reactos.org
> Envoyé le : Mardi, 22 Juillet 2008, 11h49mn 04s
> Objet : Re: [ros-dev] [ros-diffs] [ros-arm-bringup] 34655: - Build vfatfs instead of CDFS. - Load vfatfs instead of CDFS. - Implement code in the ramdisk driver to handle both ISO and FAT ramdisks. Don't know what the big deal with support ISO ramdisks was supposed to
>
> On Tue, Jul 22, 2008 at 5:42 AM, Steven Edwards wrote:
> > On Tue, Jul 22, 2008 at 1:31 AM, wrote:
> >> #include
> >> +#include "../../../filesystems/fs_rec/fs_rec.h"
> >
> > This can cause problems with parallel makes.
>
> This is what I get for commenting at 5 am...I thought you were
> including another .c file directly. ignore the part about parallel
> makes. But do try to avoid referencing the header like this. Just set
> an include path in the rbuild file and spare my eyes the horror of the
> directory traversal.
>
> --
> Steven Edwards
>
It'sToo bad the header is not in an include directory...
Kind regards,
Sylvain Petreolle (aka Usurp)
Support artists, not multinationals - http://Iwouldntsteal.net
Supportez les artistes, pas les multinationales - http://Iwouldntsteal.net