Menu
▾
▴
reactos-kernel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(64) |
Oct
(438) |
Nov
(183) |
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(132) |
May
(466) |
Jun
(366) |
Jul
(392) |
Aug
(31) |
Sep
(18) |
Oct
|
Nov
|
Dec
|
|
From: Steven E. <Ste...@ya...> - 2002-05-06 08:08:09
|
The box that will be reactos.org is up and going at reactos.dhs.org. I will move the current application and driver db code there if you havent already rewritten it in php. Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson > -----Original Message----- > From: rea...@li... > [mailto:rea...@li...] On Behalf > Of Jason Filby > Sent: Sunday, May 05, 2002 12:23 PM > To: Casper Hornstrup; rea...@li... > Cc: rea...@li... > Subject: Re: [ros-kernel] Bug-tracking systems > > > --- Casper Hornstrup <ch...@us...> wrote: > >It's time to look into bug-tracking systems for the ReactOS > project. I > >have set up two bug-tracking systems for testing. > > Ok I know.. my little reactos.org system has stalled - but > I'm going to give it more attention this week, really! And > try and get it into cvs. > > >There is the popular Bugzilla at: > >and the newer Scarab at: > > My main beef with most bug tracking systems is the way they > view the systems against which bugs are logged: as a list of > components. The idea behind rosproj (reactos.org system > nickname) is that the system is built up of a hierarchy, > which more realistically models how ReactOS is structured. > > I really promise to try and get it in cvs this week. > > - Jason > > > > > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - your guide to health and wellness http://health.yahoo.com _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: ban...@so... _______________________________________________ reactos-kernel mailing list rea...@li... https://lists.sourceforge.net/lists/listinfo/reactos-kernel |
|
From: Phillip S. <ps...@cf...> - 2002-05-06 01:00:31
|
I noticed that you made changes to the UP code, but did not fix the MP=20 code. Other than that, it seems to still be working fine for me. At 10:49 PM 5/5/2002 +0000, you wrote: >On Sun, May 05, 2002 at 11:18:33PM +0200, Casper Hornstrup wrote: > > s=F8n, 2002-05-05 kl. 23:59 skrev David Welch: > > > Hi, > > > > > > I'd like to hear of any success or failure reports with the changes to > > > irq/irql handling I committed a few days ago. > > > > Works for me. > > >Did it work before? I'm particuarly interested in the case where it >didn't. |
|
From: Hartmut B. <har...@te...> - 2002-05-06 00:29:30
|
> I have a horrible suspect... have you *also* applied my recent patch for > msvcrt read(), perchance? There is no difference with and without the _read patch. - Hartmut |
|
From: KJK::Hyperion <no...@li...> - 2002-05-05 23:41:53
|
At 00.26 06/05/2002, you wrote: >I have some problems with the new irq code. Currently, I do implement >piping for gcc. I have changed some files from np, ntoskrnl, csrss, >kernel32 and msvcrt. With the old irq code (before Philips changes), it >works. With the current irq code, it hangs after some compiled files. >There occurs no crash. For testing, I do compile vfatfs and msvcrt. If I >remove the pipe statement from makefile, so that gcc must use temporary >files, it works with the new irq code. I doesn't know whats wrong with my >changes or the irq code. I have a horrible suspect... have you *also* applied my recent patch for msvcrt read(), perchance? |
|
From: David W. <we...@cw...> - 2002-05-05 23:30:47
|
On Sun, May 05, 2002 at 04:05:19PM -0600, Brian Palmer wrote: > We need to have a loader that can do hardware detection, registry > parsing, Last Known Good Configuration, etc. Plus grub could chain load > to freeldr anyway. > Surely register parsing, LKGC, etc could be implemented by the loader regardless of the standard used to communicate with the kernel to be booted. All the kernel needs are the driver executable images themselves. Hardware detection could be implemented as an extension to the multiboot standard and shouldn't be too difficult to add to grub. |
|
From: Hartmut B. <har...@te...> - 2002-05-05 22:27:28
|
> -----Ursprungliche Nachricht----- > Von: David Welch [SMTP:we...@cw...] > Gesendet am: Sonntag, 5. Mai 2002 23:59 > An: rea...@li... > Betreff: [ros-kernel] irq fixes > > Hi, > > I'd like to hear of any success or failure reports with the changes to > irq/irql handling I committed a few days ago. > I have some problems with the new irq code. Currently, I do implement piping for gcc. I have changed some files from np, ntoskrnl, csrss, kernel32 and msvcrt. With the old irq code (before Philips changes), it works. With the current irq code, it hangs after some compiled files. There occurs no crash. For testing, I do compile vfatfs and msvcrt. If I remove the pipe statement from makefile, so that gcc must use temporary files, it works with the new irq code. I doesn't know whats wrong with my changes or the irq code. I will commit my changes in the next few days, so that everyone can test it. - Hartmut |
|
From: Brian P. <br...@sg...> - 2002-05-05 22:05:28
|
We need to have a loader that can do hardware detection, registry parsing, Last Known Good Configuration, etc. Plus grub could chain load to freeldr anyway. Brian > -----Original Message----- > From: rea...@li... [mailto:reactos-kernel- > ad...@li...] On Behalf Of David Welch > Sent: Saturday, May 04, 2002 5:52 AM > To: Brian Palmer > Subject: Re: [ros-kernel] ReactOS Multiboot Support > > On Fri, May 03, 2002 at 07:00:36PM -0600, Brian Palmer wrote: > > Is anyone here using a multiboot compliant loader to boot reactos or are > > we all just using loadros or freeldr? It seems to me that multiboot > > support in reactos is limiting it from having a much better boot > > mechanism that is tailored more for our needs as an NT clone. Plus it > > adds about 20k - 25k to freeldr.sys which I'd like to see go away. I > > propose we come up with a new boot scheme for reactos. Comments, > > suggestions? > > > I'm still using grub to boot ReactOS. What exactly is needed for a better > boot mechanism? > > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > the hardware. You get the recognition. Email Us: ban...@so... > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel |
|
From: Casper H. <ch...@us...> - 2002-05-05 22:01:44
|
man, 2002-05-06 kl. 00:49 skrev David Welch: > On Sun, May 05, 2002 at 11:18:33PM +0200, Casper Hornstrup wrote: > > s=F8n, 2002-05-05 kl. 23:59 skrev David Welch: > > > Hi, > > >=20 > > > I'd like to hear of any success or failure reports with the changes t= o=20 > > > irq/irql handling I committed a few days ago. > >=20 > > Works for me. > >=20 > Did it work before? I'm particuarly interested in the case where it=20 > didn't. >=20 No. I hadn't updated for a while, but then I updated and it crashed somewhere in the storage stack. I think it was in atapi.sys. This was in a VMware environment. |
|
From: David W. <we...@cw...> - 2002-05-05 21:48:13
|
On Sun, May 05, 2002 at 11:18:33PM +0200, Casper Hornstrup wrote: > søn, 2002-05-05 kl. 23:59 skrev David Welch: > > Hi, > > > > I'd like to hear of any success or failure reports with the changes to > > irq/irql handling I committed a few days ago. > > Works for me. > Did it work before? I'm particuarly interested in the case where it didn't. |
|
From: Casper H. <ch...@us...> - 2002-05-05 21:19:42
|
s=F8n, 2002-05-05 kl. 23:59 skrev David Welch: > Hi, >=20 > I'd like to hear of any success or failure reports with the changes to=20 > irq/irql handling I committed a few days ago. Works for me. |
|
From: Jason F. <jas...@ya...> - 2002-05-05 21:18:17
|
Hey David Tried it tonight -- it works great! - Jason --- David Welch <we...@cw...> wrote: > Hi, > > I'd like to hear of any success or failure reports with the changes > to > irq/irql handling I committed a few days ago. > > > > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com |
|
From: David W. <we...@cw...> - 2002-05-05 20:59:16
|
Hi, I'd like to hear of any success or failure reports with the changes to irq/irql handling I committed a few days ago. |
|
From: Hartmut B. <har...@te...> - 2002-05-05 20:25:13
|
Sorry, after my trouble with class2, I've forgot to commit my changes in vfatfs. - Hartmut > -----Ursprungliche Nachricht----- > Von: Phillip Susi [SMTP:ps...@cf...] > Gesendet am: Sonntag, 5. Mai 2002 21:52 > An: rea...@li... > Betreff: [ros-kernel] Raw opens of VFAT > > IIRC, someone said they were going to fix the VFAT code to support raw > opens ( I forgot who ), has this been done yet? > > > _______________________________________________________________ > > Have big pipes? SourceForge.net is looking for download mirrors. We supply > the hardware. You get the recognition. Email Us: ban...@so... > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel |
|
From: Hartmut B. <har...@te...> - 2002-05-05 20:25:12
|
services\fs\vfat\close.c: services\fs\vfat\create.c: services\fs\vfat\vfat.h: Added support for accessing the raw volume. services\fs\vfat\fsctl.c: Added support for accessing the raw volume. Disabled some debug messages. services\fs\vfat\misc.c: Implemented VfatGetUserBuffer and VfatLockUserBuffer. services\fs\vfat\rw.c: Added support for accessing the raw volume. Rewrote the read/write functions. Support for the raw volume is not complete. Some functions does not check if the file object is for a real or a raw volume. - Hartmut |
|
From: Phillip S. <ps...@cf...> - 2002-05-05 19:55:32
|
IIRC, someone said they were going to fix the VFAT code to support raw opens ( I forgot who ), has this been done yet? |
|
From: Casper H. <ch...@us...> - 2002-05-05 18:40:22
|
s=F8n, 2002-05-05 kl. 20:26 skrev Brian G.: > Are the ReactOS changes to GCC (fastcall?) implemented in the newest vers= ion of GCC? >=20 > Thanks, > Brian G. No, but you can get the patches and a patched GCC from the MinGW website. |
|
From: Brian G. <bm...@ya...> - 2002-05-05 18:26:44
|
Are the ReactOS changes to GCC (fastcall?) implemented in the newest version of GCC? Thanks, Brian G. __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com |
|
From: KJK::Hyperion <no...@li...> - 2002-05-05 17:48:21
|
Modified Files:
lib/msvcrt/io/read.c
made _read() non-greedy - it now returns as soon as any amount of data has
been read. It's the expected behavior for line-buffered streams
|
|
From: Jason F. <jas...@ya...> - 2002-05-05 16:23:12
|
--- Casper Hornstrup <ch...@us...> wrote: >It's time to look into bug-tracking systems for the ReactOS >project. I have set up two bug-tracking systems for testing. Ok I know.. my little reactos.org system has stalled - but I'm going to give it more attention this week, really! And try and get it into cvs. >There is the popular Bugzilla at: >and the newer Scarab at: My main beef with most bug tracking systems is the way they view the systems against which bugs are logged: as a list of components. The idea behind rosproj (reactos.org system nickname) is that the system is built up of a hierarchy, which more realistically models how ReactOS is structured. I really promise to try and get it in cvs this week. - Jason __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com |
|
From: Jason F. <jas...@ya...> - 2002-05-05 16:16:34
|
This is just great :)
Thanks KJK and Phillip for nailing these console bugs!
- Jason
--- Phillip Susi <ps...@cf...> wrote:
> That's what I figured, I'll fix ReadConsoleInput() in csrss.
>
> At 08:17 PM 5/4/2002 +0200, you wrote:
> >At 15.11 04/05/2002, you wrote:
> >>I've started to look at the input problems with MC now. Under
> Windows the
> >>input works fine. Under ReactOS the console is clearly reading in
> line mode.
> >>
> >>In (rosapps/mc/pc/key_nt.c) MC makes this call (line 187):
> >>win32APICALL(ReadConsoleInput(hConsoleInput, &ir, 1, &dw));
> >>
> >>It then goes on to process the one key returned. It obviously
> expects not
> >>to be in line mode.
> >
> >No, wait, it's not reading *text* from the console, it's reading
> *input*.
> >Server-side buffering doesn't apply. Input can be *every kind* of
> input
> >the user sent to the console window. The second parameter is an
> array of
> >INPUT_RECORD buffers, and INPUT_RECORD is defined as:
> >
> >typedef struct _INPUT_RECORD { // ir
> > WORD EventType;
> > union {
> > KEY_EVENT_RECORD KeyEvent;
> > MOUSE_EVENT_RECORD MouseEvent;
> > WINDOW_BUFFER_SIZE_RECORD WindowBufferSizeEvent;
> > MENU_EVENT_RECORD MenuEvent;
> > FOCUS_EVENT_RECORD FocusEvent;
> > } Event;
> >} INPUT_RECORD;
> >
> >Draw your own conclusions
> >
> >>I'm really starting to doubt that the console is expected to be
> in line
> >>mode by default... is that documented anywhere?
> >
> >Even if I'm sure it's not relevant to the issue, here you are:
> >"SetConsoleMode
> >[...]
> >dwMode
> > Specifies the input or output mode to set. If the
> hConsoleHandle
> > parameter is an input handle, the mode can be a combination of
> the
> > following values. WHEN A CONSOLE IS CREATED, ALL INPUT MODES
> EXCEPT
> > ENABLE_WINDOW_INPUT ARE ENABLED BY DEFAULT [emphasis mine].
> >
> >Value Meaning
>
>-----------------------------------------------------------------------------
> >ENABLE_LINE_INPUT The ReadFile or ReadConsole function
> returns only
> > when a carriage return character is read.
> If this
> > mode is disabled, the functions return
> when one or
> > more characters are available.
> >
> >ENABLE_ECHO_INPUT Characters read by the ReadFile or
> ReadConsole
> > function are written to the active screen
> buffer as
> > they are read. This mode can be used only
> if the
> > ENABLE_LINE_INPUT mode is also enabled.
> >
> >ENABLE_PROCESSED_INPUT CTRL+C is processed by the system and is
> not placed
> > in the input buffer. If the input buffer
> is being
> > read by ReadFile or ReadConsole, other
> control keys
> > are processed by the system and are not
> returned in
> > the ReadFile or ReadConsole buffer. If the
> > ENABLE_LINE_INPUT mode is also enabled,
> backspace,
> > carriage return, and linefeed characters
> are handled
> > by the system.
> >
> >[ENABLE_WINDOW_INPUT omitted]
> >[ENABLE_MOUSE_INPUT omitted]
> >[...]"
> >
>
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We
> supply
> the hardware. You get the recognition. Email Us:
> ban...@so...
> _______________________________________________
> reactos-kernel mailing list
> rea...@li...
> https://lists.sourceforge.net/lists/listinfo/reactos-kernel
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
|
|
From: Casper H. <ch...@us...> - 2002-05-05 15:03:46
|
Fixed warnings and error so ReactOS can be compiled with GCC 3.2. Removed unused file ntoskrnl\rtl\bitops.c |
|
From: Casper H. <ch...@us...> - 2002-05-05 12:54:49
|
It's time to look into bug-tracking systems for the ReactOS project. I have set up two bug-tracking systems for testing. There is the popular Bugzilla at: http://reactos.wox.org/bugzilla/ and the newer Scarab at: http://reactos.wox.org:8080/scarab/servlet/scarab/ Feel free to signup and try them out by entering test data in both systems. All data will be deleted eventually. Bugzilla is the most mature of the two. Scarab is 1.0 beta 6 and I have noticed a few bugs in it. Bugzilla is perl based and Scarab is based on Java servlet technology. Having looked around the two systems, my vote goes to Scarab for the following reasons: * The Scarab UI is more intuitive and have a task based (kind of like your usual Windows wizards) layout. Scarab guides you through your tasks, whereas Bugzilla usually present all information in one big form for you to fill out. * Scarab has better online help. Help is always just one click away and it opens in a new window whereas Bugzilla on some pages has a link to a large page with information (i.e. you have to leave the page to get help). * In Scarab, you get all errors at once if you forget to fill out required fields. * Scarab is more generel in it's choice of names and more flexible. In Bugzilla you create bug reports, in Scarab you create issues. In Scarab you can define an issue called bug report and define your own attributes for this issue (like description, sverity and status). You can even define their input type (basicly how they are displayed) to string, integer, drop-down list, etc. And best of all, they are searchable too! In Bugzilla you have to do with the predefined attributes like platform, summary and description. * And finally, the Scarab UI look is kick ass nice ;o) A feature that Bugzilla has that might be nice is graphing. Bugzilla has a plugin module that will graph your bug reports with dependencies between them. (Sorry, I could not install this module due to errors). Scarab seems to not have such functionality. Okay I've finished my speech, now let me hear yours. Btw. Please continue this discussion on the ros-general mailing list. Casper Hornstrup |
|
From: Steven E. <ste...@ya...> - 2002-05-05 05:31:36
|
> That's what I figured, I'll fix ReadConsoleInput() > in csrss. Kickass Dude. Once this is fixed we will have a console shell for doing development + editing while self-hosting because MC comes with a editor. We wont need windows at all anymore =) Steven __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com |
|
From: Phillip S. <ps...@cf...> - 2002-05-04 18:58:02
|
That's what I figured, I'll fix ReadConsoleInput() in csrss.
At 08:17 PM 5/4/2002 +0200, you wrote:
>At 15.11 04/05/2002, you wrote:
>>I've started to look at the input problems with MC now. Under Windows the
>>input works fine. Under ReactOS the console is clearly reading in line mode.
>>
>>In (rosapps/mc/pc/key_nt.c) MC makes this call (line 187):
>>win32APICALL(ReadConsoleInput(hConsoleInput, &ir, 1, &dw));
>>
>>It then goes on to process the one key returned. It obviously expects not
>>to be in line mode.
>
>No, wait, it's not reading *text* from the console, it's reading *input*.
>Server-side buffering doesn't apply. Input can be *every kind* of input
>the user sent to the console window. The second parameter is an array of
>INPUT_RECORD buffers, and INPUT_RECORD is defined as:
>
>typedef struct _INPUT_RECORD { // ir
> WORD EventType;
> union {
> KEY_EVENT_RECORD KeyEvent;
> MOUSE_EVENT_RECORD MouseEvent;
> WINDOW_BUFFER_SIZE_RECORD WindowBufferSizeEvent;
> MENU_EVENT_RECORD MenuEvent;
> FOCUS_EVENT_RECORD FocusEvent;
> } Event;
>} INPUT_RECORD;
>
>Draw your own conclusions
>
>>I'm really starting to doubt that the console is expected to be in line
>>mode by default... is that documented anywhere?
>
>Even if I'm sure it's not relevant to the issue, here you are:
>"SetConsoleMode
>[...]
>dwMode
> Specifies the input or output mode to set. If the hConsoleHandle
> parameter is an input handle, the mode can be a combination of the
> following values. WHEN A CONSOLE IS CREATED, ALL INPUT MODES EXCEPT
> ENABLE_WINDOW_INPUT ARE ENABLED BY DEFAULT [emphasis mine].
>
>Value Meaning
>-----------------------------------------------------------------------------
>ENABLE_LINE_INPUT The ReadFile or ReadConsole function returns only
> when a carriage return character is read. If this
> mode is disabled, the functions return when one or
> more characters are available.
>
>ENABLE_ECHO_INPUT Characters read by the ReadFile or ReadConsole
> function are written to the active screen buffer as
> they are read. This mode can be used only if the
> ENABLE_LINE_INPUT mode is also enabled.
>
>ENABLE_PROCESSED_INPUT CTRL+C is processed by the system and is not placed
> in the input buffer. If the input buffer is being
> read by ReadFile or ReadConsole, other control keys
> are processed by the system and are not returned in
> the ReadFile or ReadConsole buffer. If the
> ENABLE_LINE_INPUT mode is also enabled, backspace,
> carriage return, and linefeed characters are handled
> by the system.
>
>[ENABLE_WINDOW_INPUT omitted]
>[ENABLE_MOUSE_INPUT omitted]
>[...]"
>
|
|
From: KJK::Hyperion <no...@li...> - 2002-05-04 18:46:19
|
At 15.11 04/05/2002, you wrote:
>I've started to look at the input problems with MC now. Under Windows the
>input works fine. Under ReactOS the console is clearly reading in line mode.
>
>In (rosapps/mc/pc/key_nt.c) MC makes this call (line 187):
>win32APICALL(ReadConsoleInput(hConsoleInput, &ir, 1, &dw));
>
>It then goes on to process the one key returned. It obviously expects not
>to be in line mode.
No, wait, it's not reading *text* from the console, it's reading *input*.
Server-side buffering doesn't apply. Input can be *every kind* of input the
user sent to the console window. The second parameter is an array of
INPUT_RECORD buffers, and INPUT_RECORD is defined as:
typedef struct _INPUT_RECORD { // ir
WORD EventType;
union {
KEY_EVENT_RECORD KeyEvent;
MOUSE_EVENT_RECORD MouseEvent;
WINDOW_BUFFER_SIZE_RECORD WindowBufferSizeEvent;
MENU_EVENT_RECORD MenuEvent;
FOCUS_EVENT_RECORD FocusEvent;
} Event;
} INPUT_RECORD;
Draw your own conclusions
>I'm really starting to doubt that the console is expected to be in line
>mode by default... is that documented anywhere?
Even if I'm sure it's not relevant to the issue, here you are:
"SetConsoleMode
[...]
dwMode
Specifies the input or output mode to set. If the hConsoleHandle
parameter is an input handle, the mode can be a combination of the
following values. WHEN A CONSOLE IS CREATED, ALL INPUT MODES EXCEPT
ENABLE_WINDOW_INPUT ARE ENABLED BY DEFAULT [emphasis mine].
Value Meaning
-----------------------------------------------------------------------------
ENABLE_LINE_INPUT The ReadFile or ReadConsole function returns only
when a carriage return character is read. If this
mode is disabled, the functions return when one or
more characters are available.
ENABLE_ECHO_INPUT Characters read by the ReadFile or ReadConsole
function are written to the active screen buffer as
they are read. This mode can be used only if the
ENABLE_LINE_INPUT mode is also enabled.
ENABLE_PROCESSED_INPUT CTRL+C is processed by the system and is not placed
in the input buffer. If the input buffer is being
read by ReadFile or ReadConsole, other control keys
are processed by the system and are not returned in
the ReadFile or ReadConsole buffer. If the
ENABLE_LINE_INPUT mode is also enabled, backspace,
carriage return, and linefeed characters are handled
by the system.
[ENABLE_WINDOW_INPUT omitted]
[ENABLE_MOUSE_INPUT omitted]
[...]"
|
8 messages has been excluded from this view by a project administrator.
