Hartmut Birr wrote:
>CVSROOT: /CVS/ReactOS
>Module name: reactos
>Repository: reactos/ntoskrnl/ke/
>Changes by: hbirr(a)mok.osexperts.com 04/10/31 07:24:08
>
>Modified files:
> reactos/ntoskrnl/ke/: timer.c
>
>Log message:
> - The quantum of the idle thread must also end.
>
>
I thought that the NtYieldExecution call in PsIdleThreadMain should be
sufficient, isn't it?
Regards,
Filip
Freeldr can now be loaded as a "multiboot kernel" by multiboot compliant
bootstrap loaders like Grub. To load FreeLoader from Grub use something
like this:
title ReactOS
root (hd0,0)
kernel /freeldr.sys
You can also override settings in the [FREELOADER] section of freeldr.ini by
passing them on the command like, like this:
title ReactOS
root (hd0,0)
kernel /freeldr.sys DefaultOS=ReactOS TimeOut=0
title ReactOS (Debug)
root (hd0,0)
kernel /freeldr.sys DefaultOS=ReactOS_Debug TimeOut=0
After selecting "ReactOS" from the Grub menu you won't have to make another
selection on the freeldr menu because of the "TimeOut=0"
Gé van Geldorp.
I found a note, in Kernel Mustard's (Steve Dispensa) blog, about guarded
mutexes, which is a completely new synchronization object to me.
typedef struct _KGUARDED_MUTEX
ULONG Count;
PKTHREAD Owner;
ULONG Contention;
KGATE Gate;
WORD KernelApcDisable;
WORD SpecialApcDisable;
ULONG CombinedApcDisable;
} KGUARDED_MUTEX, *PKGUARDED_MUTEX;
What are they? KM says they are less expensive than FAST_MUTEXes.
By the way, what is a KGATE?
Emanuele
Hello, if I try to compile explorer the following error occurs:
explorer.cpp: In function `int wWinMain(HINSTANCE__*, HINSTANCE__*, TCHAR*, int)':
explorer.cpp:714: error: call of overloaded `wcsstr(TCHAR*&, const wchar_t[9])' is ambiguous
c:/mingw/bin/../lib/gcc/mingw32/3.4.1/../../../../include/string.h:119: note: candidates are: wchar_t* wcsstr(const wchar_t*, const wchar_t*)
c:/mingw/bin/../lib/gcc/mingw32/3.4.1/../../../../include/c++/3.4.1/cwchar:227: note: wchar_t* std::wcsstr(wchar_t*, wchar_t*)
...
mingw32-make: *** [explorer.o] Error 1
Is there a problem with my w32api version?
EnricoB
Hi,
currently I'm trying to get ros to work on a multiprocessor system. There
exist many problems. The major problem is a dead lock, which occurs if
different processors try to acquire the DispatcherDatabaseLock and the
PiThreadLock. Sometimes, it seems, the sequence to acquire the two locks is
different. It would be nice, if someone can look for this problem.
- Hartmut
Hi,
since there have been several reports of the ROS CDs failing to boot
with the "Invalid partition table magic" message I though if the line 85
in freeldr/fs/fs.c can be the cause. If the CD-ROM drive would get
assigned the 0x80 BIOS number (can this everr happen?) then we would end
up reading partition table from it and crash later.
Any thoughts?
Regards,
Filip
Index: freeldr/fs/fs.c
===================================================================
RCS file: /CVS/ReactOS/freeldr/freeldr/fs/fs.c,v
retrieving revision 1.14
diff -u -r1.14 fs.c
--- freeldr/fs/fs.c 25 May 2004 21:31:27 -0000 1.14
+++ freeldr/fs/fs.c 30 Oct 2004 15:01:41 -0000
@@ -82,7 +82,7 @@
}
// Check for ISO9660 file system type
- if (DriveNumber > 0x80 && FsRecIsIso9660(DriveNumber))
+ if (DriveNumber >= 0x80 && FsRecIsIso9660(DriveNumber))
{
DbgPrint((DPRINT_FILESYSTEM, "Drive is a cdrom drive. Assuming ISO-9660 file system.\n"));
Hi,
Is it okay to commit a broken port of wine Msi.dll source to our cvs? 8^P
I'm working on avdpack.dll with msiexec.exe.
I have bison working with building the port, that was not the problem.
It's this;
i386-mingw32-gcc -Wl,--base-file,base.tmp \
-Wl,--entry,_DllMain@12 \
-mdll -Wl,--image-base,0x777c0000 \
-o junk.tmp \
version.coff action.o create.o distinct.o handle.o insert.o msi.o msiquery.o order.o
package.o record.o regsvr.o select.o string.o suminfo.o table.o tokenize.o update.o where.o
sql.tab.o cond.tab.o ../../dk/w32/lib/shell32.a ../../dk/w32/lib/cabinet.a
../../dk/w32/lib/oleaut32.a ../../dk/w32/lib/ole32.a ../../dk/w32/lib/version.a
../../dk/w32/lib/user32.a ../../dk/w32/lib/advapi32.a ../../dk/w32/lib/kernel32.a
../../dk/w32/lib/libwine.a ../../dk/w32/lib/wine_uuid.a ../../dk/w32/lib/ntdll.a
Warning: resolving _MsiGetFileVersionW by linking to _MsiGetFileVersionW@20
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
action.o(.text+0x879e):action.c: undefined reference to `LoadTypeLib@8'
action.o(.text+0x8830):action.c: undefined reference to `RegisterTypeLib@12'
action.o(.text+0x88c6):action.c: undefined reference to `ITypeLib_Release'
suminfo.o(.text+0x3e):suminfo.c: undefined reference to `IPropertyStorage_Release'
suminfo.o(.text+0x324):suminfo.c: undefined reference to `IPropertySetStorage_Open'
suminfo.o(.text+0x396):suminfo.c: undefined reference to `IPropertyStorage_AddRef'
suminfo.o(.text+0x3e9):suminfo.c: undefined reference to `IPropertyStorage_Release'
suminfo.o(.text+0x3fd):suminfo.c: undefined reference to `IPropertySetStorage_Release'
suminfo.o(.text+0x569):suminfo.c: undefined reference to `IPropertyStorage_ReadMultiple'
make: *** [msi.nostrip.dll] Error 1
Thanks,
James
chorns(a)cvs.reactos.com wrote:
>CVSROOT: /CVS/ReactOS
>Module name: reactos
>Repository: reactos/tools/
>Changes by: chorns(a)mok.osexperts.com 04/10/28 12:02:01
>
>Log message:
> 2004-10-28 Casper S. Hornstrup <chorns(a)users.sourceforge.net>
>
> * drivers/net/tcpip/tests/setup.c: Include windows.h.
> * lib/gdiplus/tests/setup.c: Ditto.
> * lib/kernel32/tests/setup.c: Ditto.
> * lib/ws2_32/tests/setup.c: Ditto.
> * subsys/win32k/tests/setup.c: Ditto.
> * ntoskrnl/tests/setup.c: Ditto.
> * ntoskrnl/include/ntoskrnl.h: Include test.h.
> * ntoskrnl/mm/virtual.c (NtLockVirtualMemoryInternal): New function.
> (NtLockVirtualMemory): Use NtLockVirtualMemoryInternal.
>
>
Should we define a sort of "best practice" in inserting a little "p"
after the subsystem prefix and before the proper function's o
structure's name, to mark the *p*rivate symbols, or use the "Internal"
suffix?
1) NtpLockVirtualMemory (MmpLockVirtualMemory)
2) NtLockVirtualMemoryInternal
IMHO, not only an aesthetics problem.
Option (1) means that any symbol in ntoskrnl/include have a "p" or "P"
in their names.
> * ntoskrnl/tests/Makefile (TARGET_CFLAGS): Add -I../include.
> * ntoskrnl/tests/stubs.tst: Remove stubs for functions in libgcc.
> * regtests/shared/regtests.h: Make independent of windows.h.
> * tools/helper.mk (run): Link with libgcc.
> * tools/regtests.c (EXESTUB): Include windows.h.
> * ntoskrnl/include/internal/test.h: New file.
> * ntoskrnl/tests/tests/VirtualMemory.c: Ditto.
>
>
>
Emanuele
Hi!
I have a problem with my FPU state saving changes and v86 mode.
In ke/i386/v86m_sup.S are the functions which enter/leave v86 mode...
Ki386RetToV86Mode enters v86 mode. It changes CurrentThread->InitialStack and
TSS->Esp0 to %esp to make the exception handler run below the used stack and
not overwrite it.
The exception handler (KeV86GPF) uses a PKV86M_TRAP_FRAME, which contains a
KTRAP_FRAME at the beginning and some additional info behind. This additional
info is the data on the stack of Ki386RetToV86Mode, since it sets TSS->Esp0
to %esp, the CPU will push the trap-frame below when an exception is raised
and the additional info will be after the trap-frame.
The problem is that for reserving a FX_SAVE_AREA at the top of the
kernel-stack (without changing the KTHREAD->InitialStack value) i changed
tskswitch.S to set TSS->Esp0 to NewThread->InitialStack -
sizeof(FX_SAVE_AREA), not NewThread->InitialStack. Now if it's switching away
and back to a v86 task TSS->Esp0 will be sizeof(FX_SAVE_AREA) less than
before, and the V86 exception handler will be unable to find the additional
info from Ki386RetToV86Mode's original stack.
I am not sure how to solve it. I think it could be done by
1) Adding another variable somewhere (or maybe there is already one somewhere
which is meant to be used for this) for the exception-handler stack of the
thread, which can then be used by tskswitch.S to update TSS->Esp0.
2) only substract sizeof(FX_SAVE_AREA) from InitalStack for setting up
TSS->Esp0 in tskswitch.S if the VM bit of the EFLAGS is not set. Problem is
that the CPU unsets the VM bit if using protected-mode exception handlers for
v86 tasks, so we would need to get a copy (or pointer to) the eflags pushed
by the CPU for the IRQ handler into tskswitch.S (change
PsDispatchThread/PsDispatchThreadNoLock prototypes)
All this assumes that the FPU would never be used in V86 mode (and I hope that
this assumption is correct ;-))
Any suggestions are welcome.
- blight
Hello, I have searched for the error in the subject but can not find a solution. The daily snapshots (http://reactos.csh-consult.dk/) works fine. I have tried gcc 3.3.1, 3.4.1, 3.4.2. I use the binutils 2.15.91. Is there an error in my build tools?
EnricoB
The DDK says ExAllocatePool is obsolete. We sould use
ExAllocatePoolWithTag instead. The same applies to other generic pool APIs.
Here is a unofficial list of memory pool tags:
http://alter.org.ua/docs/win/pooltag/index.php
Emanuele
Hi,
now I have some spare time I'm back with gethostbyname and gethostbyaddr (I
don't know if they are still needed but according to my last update of my cvs
tree they are still unimplemented), I was not able to find the declaration of
PDNS_RECORDA. It would be nice to know where can I find it or at least how
can I operate with it. My research and guess makes me believe that I should
probably deal with DNS_STRUCT, but I think that would be better to have some
functionality to avoid messing with the whole structure. Am I totally lost
here?
bye
--
Carlos Manuel Duclos Vergara
carlos(a)embedded.cl
Sorry I could not translate. I was not online last weekend.
Theo
>From: "Ge van Geldorp" <gvg(a)reactos.com>
>Reply-To: ReactOS Development List <ros-dev(a)reactos.com>
>To: "'ReactOS Development List'" <ros-dev(a)reactos.com>
>Subject: RE: [ros-dev] RE: LinuxWorld Germany
>Date: Sun, 24 Oct 2004 19:57:36 +0200
>
> > From: Freeworld
> >
> > Is the translation done? When has it to be ready?
> > If nobody else does it, I could help out.
>
>Yes, the translation is already done. Thanks to apollo11 for doing it and
>thanks to you for your offer.
>
>Gé van Geldorp.
>
>
>_______________________________________________
>Ros-dev mailing list
>Ros-dev(a)reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-dev
_________________________________________________________________
Nicht lange suchen finden! MSN Suche. http://search.msn.de/ Jetzt testen!
I was recently updating my win32 QEMU installation when i noticed:
qemu-0.6.0-ppc.patch.gz
<http://www.h7.dion.ne.jp/%7Eqemu-win/download/qemu-0.6.0-ppc.patch.gz>
PReP support by F. Navara.
at the bottom. Can't go anywhere without seeing his name anymore ;)
Hehe, anyways, good job filip.
> You have to remember that our CVS is anonymous and there are many
> non-developers (much more then developers) who will be using it and have
> absolutely no interest in downloading tests, and they consider it seperate.
How will they validate what they compile? Will they trust the code and the
compilation process as is?
Emanuele
____________________________________________________________
Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione.
Abbonati subito su http://www.libero.it
> removed apps/tests). The advantage of the SVN tree will be that the
> /tests directory will have its own repository but still be included of a
> master repository/makefile for those who wish to have it all.
For when is the SVN switch planned?
Are there utilities to convert a local CVS codebase to a local SVN codebase, to
save a full checkout?
Emanuele
____________________________________________________________
Libero ADSL: navighi gratis a 1.2 Mega, senza canone e costi di attivazione.
Abbonati subito su http://www.libero.it
Moin!
What do you think about a package system for reactos' files? We could
create seperate packages for, e.g. ntoskrnl, explorer,
drivers-networking, drivers-video, etc. pp., so it would be more easy
for users to upgrade. (ros-get update and ros-get upgrade or so)
I'd like to implement this, but I still have some open questions:
- What about overwriting files which are currently "in use"? Is it
possible to overwrite them w/o rebooting?
- We need a mechanism for postinst scripts, which update registry values
and so on. cmd.exe scripts are ugly, as VBScript is. bash on
windows/reactos is IMHO also not the best way. Maybe the package
installation system (the dpkg/rpm equivalent) could parse a special
script file with the syntax like NetInstall Script. What to you think?
Sebastian
--
signature intentionally left blank.
ion(a)cvs.reactos.com wrote:
>CVSROOT: /CVS/ReactOS
>Module name: reactos
>Repository: reactos/w32api/include/reactos/wine/
>Changes by: ion(a)mok.osexperts.com 04/10/24 16:11:03
>
>Added files:
> reactos/w32api/include/reactos/: Tag: new_headers .cvsignore
> config.h debug.h defines.h
> epsapi.h heap.h helper.h
> resource.h roscfg.h string.h
> version.h
> reactos/w32api/include/reactos/wine/: Tag: new_headers cguid.h
> commctrl.h commdlg.h
> config.h cpl.h debug.h
><SNIP>
>
>Log message:
> Headers..
>
>_______________________________________________
>Ros-cvs mailing list
>Ros-cvs(a)reactos.com
>http://reactos.com/mailman/listinfo/ros-cvs
>
>
>
All right guys, I have no idea what just went on in CVS, but it somehow
got confused and started adding stuff to w32api even though I was
nowhere near that directory. So please disregard anything in my branch
that seems to have been commited in that directory, it's total nonsense.
I'll have to start over or something. I'm really getting annoyed with CVS.
Best regards,
Alex Ionescu
