> From: ion(a)svn.reactos.com
>
> Use proper PISID pointer to SID structure, fix wrong LUID
> definition, and remove duplicate code in Security Manager
>
> Updated files:
> trunk/reactos/include/ntos/security.h
Are you sure that the constants for e.g. SYSTEM_LUID need to be enclosed in
double braces for MinGW? I'd expect SYSTEM_LUID to be of type LUID. That
would make the code in ntoskrnl\se\luid.c where SYSTEM_LUID is assigned to a
LARGE_INTEGER instead of a LUID incorrect.
Gé van Geldorp.
weiden(a)svn.reactos.com schrieb:
>implemented the ProcessSessionInformation information class
>
>
>Updated files:
>trunk/reactos/ntoskrnl/ps/process.c
>
>_______________________________________________
>Ros-svn mailing list
>Ros-svn(a)reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-svn
>
>
>
>
Hi,
I think that some parts of your implementation are incorrect. The
function must check for the location of the buffer and the previous
mode. If the previous mode is user mode, the buffer must be located
within the user address space. IMHO using of MmCopyFrom/ToCaller is
better than using an exception block. It is also true for your following
commits.
- Hartmut
Hi,
I've a reactos install problem. If I select german as default language,
ros fails in second stage setup. I get a message box
'InitializeProfiles() failed'. I see that the folder 'Documents and
settings' changes to the german translation 'Dokumente und Einstellungen'.
- Hartmut
Just a late night idea. What about using the current revision number of
the local SVN repository as the build number? Major, minor and revision
number of ROS will be a matter of politics, but the build number will
give an exact coordinate in the space of the source code evolution. Is
there a way to get it in a portable way?
Emanuele
Changelog:
Add makefile for "polytest" test & enable it.
Fix compile warnings for diskspeed & zwcontinue tests
=====
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
After svn up and make clean, I get this error
ntdll: [CC] string/strstr.c
ntdll: [CC] string/strupr.c
ntdll: [CC] string/wstring.c
ntdll: [AR] ntdll.a
ntdll: [LD] ntdll.nostrip.dll
temp.exp(.edata+0x290):fake: undefined reference to `NtPlugPlayControl@12'
temp.exp(.edata+0xafc):fake: undefined reference to `ZwPlugPlayControl@12'
collect2: ld returned 1 exit status
make: *** [ntdll.nostrip.dll] Error 1
---
GNU ld version 2.15.90 20040222
GNU Make 3.80
gcc (GCC) 3.4.2 (mingw-special)
This small patch fixes a bug in getting the ip address form DNS, and
changes the time formatting to avoid internationalization issues ( .
vs , for thousands separator).
Andrew Munger
--
The cheese stands alone.
1. Add urlmon and shdocvw to the build
2. wget the mozilla control from there
"Url"="http://crossover.codeweavers.com/redirect/mozcontrol"
3. Install the control (It may fail a few times)
4. Copy msvcr70.dll to reactos\system32
5. start cmd.exe and cd to C:\program files\Mozilla ActiveX Control .....
6. type explorer
7. hit the webbutton
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
ion(a)svn.reactos.com wrote:
>Fix remaning ROS bugs. A minor hack has been added to ObCreateObject because it seems that gcc doesn't dword-align the stacks?!! Thanks to w3seek for some of the ex patches.
>
>
>
After what has now become 6 hours of work, I'm done fixing this stuff.
ROS should be usable, but I haven't ran full regression tests...probably
a lot of stuff is still broken.
Best regards,
Alex Ionescu
Hi,
Booting ROS doesn't work lately...... I've debugged the problem and
found two likely causes:
1) RtlFormatCurrentUserKeyPath calls NtQueryInformationToken with a
Kernel Mode address while in user-mode
2) Something is wrong with setting the current mode (in syscall.S), and
so MmCopySafe... thinks that teh current mode is user while the buffer
is kernel:
(mm/mm.c:60) 1, de1c7cf8
Note that 1 == UserMode while the buffer is kernel-mode.
It's late here so I don't have time to look into it with more detail.
Best regards,
Alex Ionescu
If we
#define ASSERT(x) if (0) { x }
for DBG := 0, won't all these compile errors go away? We have a lot of them.
The compiler will perform syntax check, but optimize the statements away.
Casper
________________________________
From: ros-diffs-bounces(a)reactos.com [mailto:ros-diffs-bounces@reactos.com] On Behalf Of weiden(a)svn.reactos.com
Sent: 21. januar 2005 18:17
To: ros-diffs(a)reactos.com
Subject: [ros-diffs] [weiden] 13188: fixed ASSERT statement,thanks to blight for pointing it out
fixed ASSERT statement, thanks to blight for pointing it out
Modified: trunk/reactos/ntoskrnl/ob/object.c
________________________________
Modified: trunk/reactos/ntoskrnl/ob/object.c
--- trunk/reactos/ntoskrnl/ob/object.c 2005-01-21 16:50:11 UTC (rev 13187)
+++ trunk/reactos/ntoskrnl/ob/object.c 2005-01-21 17:17:13 UTC (rev 13188)
@@ -51,7 +51,7 @@
NTSTATUS Status = STATUS_SUCCESS;
/* at least one output parameter must be != NULL! */
- ASSERT((ULONG_PTR)SecureObjectInformation ^ (ULONG_PTR)ObjectName != 0);
+ ASSERT((ULONG_PTR)CapturedObjectAttributes ^ (ULONG_PTR)ObjectName != 0);
if(ObjectAttributes == NULL)
{
This is just a note for the WIN32K developers.
I ran the dumppe utility to compare imported symbols in WIN32K.SYS on a
real system and on ROS'. Here are the results.
ReactOS WIN32K.SYS exported symbols containg substing "Port":
ZwConnectPort
ZwRequestWaitReplyPort
XPSP2 WIN32K.SYS exported symbols containg substing "Port":
LpcRequestWaitReplyPort
PsGetProcessDebugPort
LpcRequestPort
This suggests port handles are not used in regular LPC processing within
WIN32K and that there is not a twin connection to \Windows\ApiPort
(ntuser/csr.c).
Emanuele (just guessing)
I've been doing some looking at why winext2fsd doesn't work on reactos.
This has been a pet project of mine for a while, but sadly I'm not very
skilled in the parts of reactos that it touches.
On the ext2 branch, I've got filips changes and some small changes of
my own so that I can make a bootcd that will try to install reactos on
a fresh ext2 partition.
ext2 starts writing the first file to the empty filesystem but stalls
when a call to WriteCacheSegment causes ext2 to do a paging write of
several pages to class2, which uses ScsiClassSplitRequests to send
several blocks to scsiport for writing. The interesting thing is, in
the case where my diff prints DEADLY WAIT, SpiProcessRequests receives
the IRPs but does not enter the while loop that would process them,
nor receive any further completions. At this point i'm totally stuck
and so I'll try to isolate the relevant debug output.
If somebody is interested and has some spare time I'd appreciate a
bit of wisdom about how the DeviceExtension->Flags, NextIrp,
ActiveIrpCount and PendingIrpCount fit together. I think that if
the IRPs are completed then the rest will work, since the split
IRP code in class2 seems reasonable.
http://64.81.145.152/~arty/ext2.diff <-- Lots of annotation
http://64.81.145.152/~arty/ext2.log <-- Last part of execution
http://64.81.145.152/~arty/rosbin.zip <-- Binaries from my tree
In the log it is writing atapi.sys to \ReactOS\system32\drivers on the
disk. DEADLY WAIT(0) is the place where ext2 can't progress from. It's
at line 200 or so in drivers/fs/ext2/src/io.c.
The fatal invocation of SpiProcessRequest looks like this before the
while loop:
(scsiport.c:2864) DeviceExtension->Flags & IRP_FLAG_COMPLETE 0
(scsiport.c:2866) DeviceExtension->SrbExtensionSize 0
(scsiport.c:2869) DeviceExtension->CurrentSrbExtensions 0 Max 0
(scsiport.c:2871) DeviceExtension->PendingIrpCount 4
(scsiport.c:2873) DeviceExtension->Flags & (N|NLU) 0
(scsiport.c:2875) DeviceExtension->NextIrp c0457db0
The wierd thing is that it seems that atapi relies on the ide controller
raising an interrupt after IDEWriteBlock, which never happens for me
under qemu after this point. This is where I get totally lost
unfortunately.
I'll try to learn more as I go but any help understanding scsiport is
appreciated.
Art
--
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman
The magic number 1 may be obvious to some, but it isn't to all.
It should be true/false, yes/no or all of the above.
Casper
________________________________
From: ros-diffs-bounces(a)reactos.com [mailto:ros-diffs-bounces@reactos.com] On Behalf Of royce(a)svn.reactos.com
Sent: 20. januar 2005 07:37
To: ros-diffs(a)reactos.com
Subject: [Spam] [ros-diffs] [royce] 13154: require attributes to have values
require attributes to have values
Modified: branches/xmlbuildsystem/reactos/ntoskrnl/ntoskrnl.xml
Modified: branches/xmlbuildsystem/reactos/tools/rbuild/XML.cpp
Modified: branches/xmlbuildsystem/reactos/tools/rbuild/module.cpp
________________________________
Modified: branches/xmlbuildsystem/reactos/ntoskrnl/ntoskrnl.xml
--- branches/xmlbuildsystem/reactos/ntoskrnl/ntoskrnl.xml 2005-01-20 06:29:08 UTC (rev 13153)
+++ branches/xmlbuildsystem/reactos/ntoskrnl/ntoskrnl.xml 2005-01-20 06:36:37 UTC (rev 13154)
@@ -29,7 +29,7 @@
<directory name="ke">
<if property="ARCH" value="i386">
<directory name="i386">
- <file first>multiboot.S</file>
+ <file first="1">multiboot.S</file>
<file>bios.c</file>
<file>brkpoint.c</file>
<file>bthread.S</file>
I'm re setting up my ROS dev environment, after a format/reinstall, and
i'm encountering the following problem under both QEMU and ReactOS:
While booting from the livecd or the bootcd i get an inaccessible boot
device error. The HD partition on VMWare is a FAT32 partition formatted
in win98, the partition in QEMU is an unformatted partition.
Any idea on how to fix this?
Since binutils-2.15.90 (which you need to build a bootable ReactOS) is no
longer available from the MinGW download pages, I put it on the ReactOS
download page on SourceForge:
http://sourceforge.net/project/showfiles.php?group_id=6553
Gé van Geldorp.
Hi,
currently our Zw functions for kernel mode are implemented by an
parameter wrapper and an int 0x2e instruction. The only reason for using
the Zw functions in kernel mode is to bypass the buffer check. Can we
implement the Zw functions by saving/changing/restoring the previous
mode and calling the equal Nt function?
- Hartmut
Currently the resource files in comdlg contain a listbox entry similar
to below:
LISTBOX IDC_SHELLSTATIC,4,20,272,85, LBS_SORT |
LBS_NOINTEGRALHEIGHT | LBS_MULTICOLUMN | WS_HSCROLL | NOT WS_VISIBLE
shouldn't it be
LISTBOX IDC_SHELLSTATIC,4,20,272,85, LBS_SORT |
LBS_NOINTEGRALHEIGHT | LBS_MULTICOLUMN | WS_HSCROLL
the NOT WS_VISIBLE causes windres errors (windres doesn't recognize NOT,
and even if it did, saying NOT WS_VISIBLE instead of just not |
WS_VISIBLE is redundant.), which causes the DLL to fail to build. While
this appears to be merely a goofup, figured i'd ask about it in the list
before i make any changes to the tree in case this is there for a reason.
Richard
royce(a)svn.reactos.com wrote:
> added 'first' attribute to <file>
> Modified: branches/xmlbuildsystem/reactos/ntoskrnl/ntoskrnl.xml
...
> + <file first>multiboot.S</file>
According to the XML spec, all attributes must have a value. [1]
So, the above line must be written like this:
<file first="true">multiboot.S</file>
[1] http://www.w3.org/TR/REC-xml/#NT-Attribute
--
d_layer
That should be:
<file first="yes">multiboot.S</file>
or similar.
Modified: branches/xmlbuildsystem/reactos/ntoskrnl/ntoskrnl.xml
--- branches/xmlbuildsystem/reactos/ntoskrnl/ntoskrnl.xml 2005-01-19 01:11:43 UTC (rev 13128)
+++ branches/xmlbuildsystem/reactos/ntoskrnl/ntoskrnl.xml 2005-01-19 01:37:35 UTC (rev 13129)
@@ -26,10 +26,10 @@
</output>
</invoke>
- <directory name="ke"> <!-- leave this at the top -->
+ <directory name="ke">
<if property="ARCH" value="i386">
<directory name="i386">
- <file>multiboot.S</file> <!-- leave this at the top -->
+ <file first>multiboot.S</file>
<file>bios.c</file>
<file>brkpoint.c</file>
<file>bthread.S</file>
hbirr(a)svn.reactos.com wrote:
>- Set the limit of the user mode code/data segment back to 4GB.
>
>
>
>Updated files:
>trunk/reactos/ntoskrnl/ke/i386/gdt.c
>
>
>
Thanks!
Do you know however if any of ROS Kernel depends on the old GDT? There
are two weird issues with SYSEXIT:
1) GvG reported that FPU is broken
2) Explorer now crashes in shlwapi when clicking on a disk.
Best regards,
Alex Ionescu