reactos-kernel

AW: [ros-kernel] fprintf brokeness?

[Hartmut B. <har...@te...>]

Some time ago, I've found this bug in vfprintf.c/vfwprint.c, but I've forgot to commit the fix.

- Hartmut


> -----Ursprungliche Nachricht-----
> Von:	Steven Edwards [SMTP:ste...@ya...]
> Gesendet am:	Donnerstag, 13. Juni 2002 14:21
> An:	rea...@li...
> Betreff:	Re: [ros-kernel] fprintf brokeness?
> 
> > What do you mean the text output is garbled. I
> > compiled and ran it just fine
> > under W2K using mingw 1.1. All the text look okay or
> > are you meaning under
> > ReactOS?
> 
> Yeah sorry about that. 4am is not the best time to be
> doing bug reports =). What I meant was the text output
> is garbled under ReactOS but works fine under
> WIndows/WINE. I think its just our fprintf but am not
> 100% sure. I tired to look at the source for WINE's
> msvcrt and see if there was something wrong with ours
> but had no luck figuring it out.
> 
> Thanks
> Steven

AW: [ros-kernel] NtDuplicateObject

[Hartmut B. <har...@te...>]

> >DuplicateHandle from kernel32 and some calls to NtDuplicateHandle from
> >kernel32\create.c needs this check. If the check is removed in
> >NtDuplicateHandle, the check must added in this functions.
>
> I don't understand why. What's the matter with duplicating inheritable 
handles?
>

While implementing of c-runtime-piping, I had some problems with duplicated 
handles. I'm not sure, if the problem was in NtDuplicateObject or in 
ObCreateHandleTable.

- Hartmut

Re: [ros-kernel] DocBook authoring tools

[KJK::Hyperion <no...@li...>]

At 22.52 12/06/2002, you wrote:
>They are free for personal use and professional use.
>They work almost out of the box.

"almost"? ;-(

>Note: they are Java applications, therefore you need at least a 400 MHz 
>processor with 256 Mbyte RAM.

ack! personally, I think Java apps suck, and deserve a quick, silent 
death... what about native applications? on Windows a supposedly cool 
program is XML Cooktop - but in fact it sucks. May I suggest SciTE? works 
on Windows and Linux, it's not specifically a XML editor but a generic code 
editor, like ViM. Unlike ViM, it's usable. But, unlike "real" XML editors, 
it's not DTD-aware, i.e. no pretty property boxes, you have to do it the 
hard way, by hand. Good thing is that you can also use it as C/C++ editor 
(in fact, I did all my coding for ReactOS with SciTE), but it supports a 
ton of other languages as well (Ruby, Python, Pascal, Ada, Perl, OLE IDL, 
PHP, SQL, PLSQL, resource scripts, TCL, VB, etc.). Plus, no crazy memory or 
CPU requirements, a Pentium 133 with 16 MB RAM will do

check it out:
<http://www.scintilla.org/SciTE.html>

(the default config, as usual, works only for the developer. Before using 
it, read the manual, or you may miss some cool features)

[ros-kernel] CVS Commit: reactos

[Eric K. <ek...@rz...>]

ntoskrnl/include/internal/ldr.h
ntoskrnl/io/device.c
ntoskrnl/io/driver.c
ntoskrnl/ldr/loader.c
    Fixed driver unloading upon failing initialization.


Eric

Re: [ros-kernel] FreeLoader builds and works!

[Eric K. <ek...@rz...>]

"Brian Palmer" <br...@sg...> wrote:


> You can't build FreeLoader using which cmd? The Windows NT/2k/XP cmd.exe
> or the ReactOS cmd.exe?

I meant the ReactOS cmd.exe! I didn't test NT/2k/XP cmd.exe yet!

Eric

Re: [ros-kernel] fprintf brokeness?

[Steven E. <ste...@ya...>]

> What do you mean the text output is garbled. I
> compiled and ran it just fine
> under W2K using mingw 1.1. All the text look okay or
> are you meaning under
> ReactOS?

Yeah sorry about that. 4am is not the best time to be
doing bug reports =). What I meant was the text output
is garbled under ReactOS but works fine under
WIndows/WINE. I think its just our fprintf but am not
100% sure. I tired to look at the source for WINE's
msvcrt and see if there was something wrong with ours
but had no luck figuring it out.

Thanks
Steven

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

RE: [ros-kernel] Patch: Teach freeldr registry aboutmultiandexpanded types

[Aliberti E. <ea...@us...>]

>The ability to cast arrays to pointers without using & is a compiler
>trick. A dangerous trick IMHO.

It's not casting. Arrays ARE pointers in C. Square brackets are a language construct to avoid explicit pointer computations.

Re: [ros-kernel] fprintf brokeness?

[James M. <jid...@sa...>]

What do you mean the text output is garbled. I compiled and ran it just fine
under W2K using mingw 1.1. All the text look okay or are you meaning under
ReactOS?


James Marjie
GnuPG KeyID:    0x7C837497

"Take your life in your own hands, and what happens? A terrible thing: no
one to blame." -Erica Jong

[ros-kernel] fprintf brokeness?

[Steven E. <ste...@ya...>]

Anyone got time to look at this?
This works right under Windows/WINE but the text
output is garbled.

Thanks
Steven

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

RE: [ros-kernel] Patch: Teach freeldr registry about multiandexpanded types

[Casper H. <ch...@us...>]

tor, 2002-06-13 kl. 03:10 skrev Brian Palmer:
> > ons, 2002-06-12 kl. 05:44 skrev Brian Palmer:
> > 
> > These are some changes I made to remove the warnings. They are not
> part
> > of Joseph's patch.
> > 
> > > I have a few questions about this:
> > >
> > > reactos.c line 193:
> > > rc = RegQueryValue(hGroupKey, "List", NULL, (PUCHAR)&ValueBuffer,
> > > &BufferSize);
> > >
> > > Shouldn't that be:
> > > rc = RegQueryValue(hGroupKey, "List", NULL, (PUCHAR)ValueBuffer,
> > > &BufferSize);
> > >
> > 
> > They are both okay due to the way the compiler handles char arrays.
> The
> > first makes more sence to me because it takes the address of the array
> > and then casts it to a PUCHAR (ie. it casts a pointer to another
> > pointer). The second casts a char[] array to PUCHAR (ie. an array to
> > pointer cast).
> 
> This is incorrect. ValueBuffer is a pointer. This is how you can take a
> regular pointer and use it like it was an array. So you are passing in
> the address of the pointer to the array. Try printing the values of the
> two addresses and you will see that they are different.
> 
> > > And the same thing in meminit.c line 64. Since BiosMemoryMap is a
> > > pointer to the array, you are passing in the address of the pointer
> to
> > > the array and casting it to type PBIOS_MEMORY_MAP.
> > >
> > 
> > No. BiosMemoryMap is on the stack in MmInitializeMemoryManager(),
> > defined as BIOS_MEMORY_MAP BiosMemoryMap[32]. It is not a pointer.
> > Wether it should be on the stack is debatable because it is retrieved
> > from the BIOS twice (from what I gather), once by the memory manager
> and
> > once by the ReactOS boot code.
> 
> Again, BiosMemoryMap is just a pointer, so all you are putting on the
> stack is 4 bytes. The compiler actually interprets a parameter such as
> this to be just a pointer. That's why if you use sizeof() on a function
> parameter that is an array it will only return 4 instead of the size of
> the array. If you run lint on code that does this it will throw an error
> at you.
> 
> > > I also noticed that this patch changes all the function prototypes
> from
> > > ULONG GetBiosMemoryMap(BIOS_MEMORY_MAP BiosMemoryMap[32]); to ULONG
> > > GetBiosMemoryMap(PBIOS_MEMORY_MAP BiosMemoryMap); Now this would
> > > normally be fine except that that function returns an array of
> exactly
> > > 32 items since the size of the memory map is not known before the
> > > function call.
> > 
> > Yes that is a bit unsafe. Maybe we should rename BIOS_MEMORY_MAP to
> > BIOS_MEMORY_MAP_ENTRY and create a new type for the bios memory map?
> > 
> > typedef BIOS_MEMORY_MAP_ENTRY BIOS_MEMORY_MAP[32];
> > typedef BIOS_MEMORY_MAP *PBIOS_MEMORY_MAP;
> > 
> > That way we can avoid some type casts.
> 

I just confirmed that the addresses are equal with this little program.

#include <stdio.h>
#include <windows.h>

typedef struct
{
	ULONG	BaseAddressLow;
	ULONG	BaseAddressHigh;
	ULONG	LengthLow;
	ULONG	LengthHigh;
	ULONG	Type;
	ULONG	Reserved;
} PACKED BIOS_MEMORY_MAP, *PBIOS_MEMORY_MAP;

int
main(int argc, char *argv[])
{
  BIOS_MEMORY_MAP BiosMemoryMap[32];

  printf("BiosMemoryMap @ 0x%lx\n", (PUCHAR)&BiosMemoryMap);
  printf("BiosMemoryMap @ 0x%lx\n", (PUCHAR)BiosMemoryMap);
  printf("sizeof(BiosMemoryMap) = %d\n", sizeof(BiosMemoryMap));

  return 0;
}

Gives for me:

BiosMemoryMap @ 0x22fc60
BiosMemoryMap @ 0x22fc60
sizeof(BiosMemoryMap) = 768

The ability to cast arrays to pointers without using & is a compiler
trick. A dangerous trick IMHO.

> I think I will just create a structure called BIOS_MEMORY_MAP_ARRAY. It
> will have one member of type BIOS_MEMORY_MAP which is an array of 32
> items. And I'll change this function to take a PBIOS_MEMORY_MAP_ARRAY
> pointer as a parameter. What do you think?

A just as good solution IMO.

Casper

RE: [ros-kernel] wine dll's on a real system.

[Steven E. <Ste...@ya...>]

> I got the wine dll's from Steven and installed them on a 
> win2k server I have, 
> on a ADM Athlon XP1600,  256 ram, and servral gb of disk.
> I documented what I saw, and the results are not good. :-(, 
> This is the first round, so I will be patient. a few notes:

Thanks for your time in testing Diego, lets hope next time WINE will be
a little more stable for you =). If you are still interested in doing
some testing I will keep you posted on my progress with the wine port. I
have taken the past week off to focus on a few other things but am
forwarding your report to wine-devel and will be resuming work this
weekend. 

Thanks Again
Steven

"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson 

RE: [ros-kernel] FreeLoader builds and works!

[Brian P. <br...@sg...>]

You can't build FreeLoader using which cmd? The Windows NT/2k/XP cmd.exe
or the ReactOS cmd.exe?

Brian

> -----Original Message-----
> From: rea...@li...
[mailto:reactos-kernel-
> ad...@li...] On Behalf Of Eric Kohl
> Sent: Wednesday, June 12, 2002 7:37 PM
> To: ReactOS Kernel
> Subject: [ros-kernel] FreeLoader builds and works!
> 
> Hi!
> 
> I have to apologise for the trouble I might have caused!
> 
> After downloading and installing the latest DJGPP, FreeLoader builds
> without
> causing any problems. But it is important to note that you cannot
build
> FreeLoader using cmd. DJGPP wants command.com to run well.
> 
> Eric
> 
> 
> 
> 
> _______________________________________________________________
> 
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel

[ros-kernel] FreeLoader builds and works!

[Eric K. <ek...@rz...>]

Hi!

I have to apologise for the trouble I might have caused!

After downloading and installing the latest DJGPP, FreeLoader builds without
causing any problems. But it is important to note that you cannot build
FreeLoader using cmd. DJGPP wants command.com to run well.

Eric

RE: [ros-kernel] Patch: Teach freeldr registry about multiandexpanded types

[Brian P. <br...@sg...>]

> -----Original Message-----
> From: rea...@li...
[mailto:reactos-kernel-
> ad...@li...] On Behalf Of Casper Hornstrup
> Sent: Wednesday, June 12, 2002 7:34 AM
> To: rea...@li...
> Subject: RE: [ros-kernel] Patch: Teach freeldr registry about
> multiandexpanded types
> 
> ons, 2002-06-12 kl. 05:44 skrev Brian Palmer:
> 
> These are some changes I made to remove the warnings. They are not
part
> of Joseph's patch.
> 
> > I have a few questions about this:
> >
> > reactos.c line 193:
> > rc = RegQueryValue(hGroupKey, "List", NULL, (PUCHAR)&ValueBuffer,
> > &BufferSize);
> >
> > Shouldn't that be:
> > rc = RegQueryValue(hGroupKey, "List", NULL, (PUCHAR)ValueBuffer,
> > &BufferSize);
> >
> 
> They are both okay due to the way the compiler handles char arrays.
The
> first makes more sence to me because it takes the address of the array
> and then casts it to a PUCHAR (ie. it casts a pointer to another
> pointer). The second casts a char[] array to PUCHAR (ie. an array to
> pointer cast).

This is incorrect. ValueBuffer is a pointer. This is how you can take a
regular pointer and use it like it was an array. So you are passing in
the address of the pointer to the array. Try printing the values of the
two addresses and you will see that they are different.

> > And the same thing in meminit.c line 64. Since BiosMemoryMap is a
> > pointer to the array, you are passing in the address of the pointer
to
> > the array and casting it to type PBIOS_MEMORY_MAP.
> >
> 
> No. BiosMemoryMap is on the stack in MmInitializeMemoryManager(),
> defined as BIOS_MEMORY_MAP BiosMemoryMap[32]. It is not a pointer.
> Wether it should be on the stack is debatable because it is retrieved
> from the BIOS twice (from what I gather), once by the memory manager
and
> once by the ReactOS boot code.

Again, BiosMemoryMap is just a pointer, so all you are putting on the
stack is 4 bytes. The compiler actually interprets a parameter such as
this to be just a pointer. That's why if you use sizeof() on a function
parameter that is an array it will only return 4 instead of the size of
the array. If you run lint on code that does this it will throw an error
at you.

> > I also noticed that this patch changes all the function prototypes
from
> > ULONG GetBiosMemoryMap(BIOS_MEMORY_MAP BiosMemoryMap[32]); to ULONG
> > GetBiosMemoryMap(PBIOS_MEMORY_MAP BiosMemoryMap); Now this would
> > normally be fine except that that function returns an array of
exactly
> > 32 items since the size of the memory map is not known before the
> > function call.
> 
> Yes that is a bit unsafe. Maybe we should rename BIOS_MEMORY_MAP to
> BIOS_MEMORY_MAP_ENTRY and create a new type for the bios memory map?
> 
> typedef BIOS_MEMORY_MAP_ENTRY BIOS_MEMORY_MAP[32];
> typedef BIOS_MEMORY_MAP *PBIOS_MEMORY_MAP;
> 
> That way we can avoid some type casts.

I think I will just create a structure called BIOS_MEMORY_MAP_ARRAY. It
will have one member of type BIOS_MEMORY_MAP which is an array of 32
items. And I'll change this function to take a PBIOS_MEMORY_MAP_ARRAY
pointer as a parameter. What do you think?

> >
> > Also the %ld in the strings passed to printf() is not supported in
the
> > printf() function included with freeldr. It should probably be
updated.
> 
> I did not notice that ;o(
> 
> >
> > Thanks for the patch, every little bit helps.
> >
> > Brian
> 
> 
> 
> _______________________________________________________________
> 
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel

[ros-kernel] CVS Commit: reactos

[Eric K. <ek...@rz...>]

bootc.lst
system.hiv
    Added new drivers to system.hiv and removed some from bootc.lst.

drivers/fs/fs_rec/cdfs.c
drivers/fs/fs_rec/fat.c
drivers/fs/fs_rec/ntfs.c
ntoskrnl/include/internal/io.h
ntoskrnl/io/device.c
ntoskrnl/io/driver.c
ntoskrnl/ke/main.c
ntoskrnl/ldr/loader.c
subsys/system/services/database.c
    Implemented a new driver loading scheme (registry-based).
    NtLoadDriver() now uses a drivers registry path instead of its full
filename.

subsys/smss/init.c
    NtSetSystemInformation() is now used to load win32k.sys.

lib/ntdll/rtl/registry.c
ntoskrnl/cm/rtlfunc.c
    RtlpGetRegistryHandle(): Don't remove a leading backslash in an absolute
registry path.

This patch implements the registry-based driver loading for system-start
drivers and auto-start drivers. Debug symbol loading and driver unloading is
still broken but will be fixed next. Boot-start drivers are still loaded and
initialized the old way. User-mode services can not be run yet.


Eric

[ros-kernel] Patch: Support usermode %wZ format specifier and fix RtlEqualSid

[Joseph G. <gal...@va...>]

Patch1.diff:

ntoskrnl\se\sid.c
lib\ntdll\rtl\sid.c

- Fix bug that caused all sids with the
  same number of relative ids to compare
  equal.

---
Patch2.diff:

I'm not sure why the %Z format specifier was
#if 0'd out -- so I don't know for sure that
we want this patch; however, here it is.

TokenTest uses it to display UNICODE_STRINGS.

lib/crtdll/stdio/vfprintf.c
lib/msvcrt/stdio/vfprintf.c

- Enable %Z format specifier and
  fix bugs that prevented it from
  working.

Thanks,

Joseph

[ros-kernel] DocBook authoring tools

[Aliberti E. <ea...@us...>]

I just want to suggest you use these two excellent (beta) tools for 
DocBook authoring (rosdocs module):

XMLmind XML Editor
http://www.xmlmind.com/xmleditor/

XMLmind FO Converter
http://www.xmlmind.com/foconverter/

They are free for personal use and professional use.

They work almost out of the box.

Note: they are Java applications, therefore you need at least a 400 
MHz processor with 256 Mbyte RAM.

e

Re: [ros-kernel] wine dll's on a real system.

[James M. <jid...@sa...>]

Check out http://www.dependencywalker.com/ . It give a nice little map for a
file dependencies.

James Marjie
GnuPG KeyID:    0x7C837497

"Take your life in your own hands, and what happens? A terrible thing: no
one to blame." -Erica Jong

Re: [ros-kernel] Crash on boot w/ no CDROM

[Eric K. <ek...@rz...>]

"Joseph Galbraith" <gal...@va...> wrote:

> Hope I haven't been stepping on toes or anything --
> I'm very excited about this project.  It looks
> to be a lot of fun.

No! At least you did not step on my toes! ;-)
You pointed me to some broken lines of code that will have to be fixed.

Thanks a lot!

Eric

[ros-kernel] NtQuerySystemInformation

[<cra...@mi...>]

here is a mini patch for sysinfo.c
I ve joined the code for the Ke function that is setting KeMinimumIncrement/KeMaximumIncrement too.

btw Is there anyone working on QuerySystemInformation() ?

other thing:
QSI_DEF(SystemPathInformation)
{
	/* FIXME: QSI returns STATUS_BREAKPOINT. Why? */
	return (STATUS_BREAKPOINT);
}
==> DbgPrint("EX: SystemPathInformation now available via SharedUserData\n")
here is the answer.

And i got a last question about win2k kernel well maybe ROS kernel too.
Do you know when the  pServiceDescriptorTable field of struct _KTHREAD (offset 0xDC) is used ?
I know it's set by PsCreateProcess, that's all.

bye

[ros-kernel] wine dll's on a real system.

[Diego I. <ias...@ac...>]

Hello gang, 

I got the wine dll's from Steven and installed them on a win2k server I have, 
on a ADM Athlon XP1600,  256 ram, and servral gb of disk.
I documented what I saw, and the results are not good. :-(, 
This is the first round, so I will be patient. a few notes:
  * windows dies means I see the screen getting black and I see the bios again
  * please ingnore the spelling/ grammar orros in the text attached.
  * if you can, you can tell me if there is a way to see which programs use 
which dll, that would make my life easier. 

 - diego

-- 
bureaucracy, n:
	A method for transforming energy into solid waste.

[ros-kernel] QuerySystemInformation mini patch

[<cra...@mi...>]

see the attached file.
I would like to know if someone is already working on this API ?

last thing:
QSI_DEF(SystemPathInformation)
{
	/* FIXME: QSI returns STATUS_BREAKPOINT. Why? */
	return (STATUS_BREAKPOINT);
}
==> DbgPrint("EX: SystemPathInformation now available via SharedUserData\n")
here is the answer.

-- crazylord

RE: [ros-kernel] Patch: Teach freeldr registry about multi andexpanded types

[Casper H. <ch...@us...>]

ons, 2002-06-12 kl. 05:44 skrev Brian Palmer:

These are some changes I made to remove the warnings. They are not part
of Joseph's patch.

> I have a few questions about this:
> 
> reactos.c line 193:
> rc = RegQueryValue(hGroupKey, "List", NULL, (PUCHAR)&ValueBuffer,
> &BufferSize);
> 
> Shouldn't that be:
> rc = RegQueryValue(hGroupKey, "List", NULL, (PUCHAR)ValueBuffer,
> &BufferSize);
> 

They are both okay due to the way the compiler handles char arrays. The
first makes more sence to me because it takes the address of the array
and then casts it to a PUCHAR (ie. it casts a pointer to another
pointer). The second casts a char[] array to PUCHAR (ie. an array to
pointer cast).

> And the same thing in meminit.c line 64. Since BiosMemoryMap is a
> pointer to the array, you are passing in the address of the pointer to
> the array and casting it to type PBIOS_MEMORY_MAP.
> 

No. BiosMemoryMap is on the stack in MmInitializeMemoryManager(),
defined as BIOS_MEMORY_MAP BiosMemoryMap[32]. It is not a pointer.
Wether it should be on the stack is debatable because it is retrieved
from the BIOS twice (from what I gather), once by the memory manager and
once by the ReactOS boot code.

> I also noticed that this patch changes all the function prototypes from
> ULONG GetBiosMemoryMap(BIOS_MEMORY_MAP BiosMemoryMap[32]); to ULONG
> GetBiosMemoryMap(PBIOS_MEMORY_MAP BiosMemoryMap); Now this would
> normally be fine except that that function returns an array of exactly
> 32 items since the size of the memory map is not known before the
> function call.

Yes that is a bit unsafe. Maybe we should rename BIOS_MEMORY_MAP to
BIOS_MEMORY_MAP_ENTRY and create a new type for the bios memory map?

typedef BIOS_MEMORY_MAP_ENTRY BIOS_MEMORY_MAP[32];
typedef BIOS_MEMORY_MAP *PBIOS_MEMORY_MAP;

That way we can avoid some type casts.

> 
> Also the %ld in the strings passed to printf() is not supported in the
> printf() function included with freeldr. It should probably be updated.

I did not notice that ;o(

> 
> Thanks for the patch, every little bit helps.
> 
> Brian

Re: [ros-kernel] Crash on boot w/ no CDROM

[Casper H. <ch...@us...>]

ons, 2002-06-12 kl. 15:55 skrev Joseph Galbraith:
> Great!
> 
> I'm happy now that I can boot again :-)
> 
> Hope I haven't been stepping on toes or anything --
> I'm very excited about this project.  It looks
> to be a lot of fun.
> 
> - Joseph

Sounds great!

If you plan to stick around you can ask Rex Jolliff
<re...@lv...> for a CVS account.

Casper

Re: [ros-kernel] Patch: don't crash if DriverEntry fails

[Casper H. <ch...@us...>]

ons, 2002-06-12 kl. 06:14 skrev Joseph Galbraith:
> io/device.c
> io/driver.c
> ldr/loader.c
> 
> * Call RtlCreateUnicodeString() instead of
>   RtlInitUnicodeString() when initializing
>   the DeviceNode->ServiceName, since
>   IopFreeDeviceNode() will use RtlFreeUnicodeString()
>   on it.
> 
> * Call ObDerefernceObject() instead of
>   ExFreePool() to release the DeviceObject
>   if DriverEntry fails. (Thanks, Eric.)
> 
> Thanks,
> 
> - Joseph

Applied. Thanks for the patch.

ReactOS now boots for me again ;o)

Casper