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: Phillip S. <ps...@cf...> - 2002-05-04 16:25:08
|
The platform SDK page on SetConsoleMode() documents it. Are you sure it doesn't call SetConsoleMode() somewhere? It could possibly be that ReadConsoleInput ignores the line buffering, because it gets other events besides char input. I think that is what it is actually, though it isn't documented in the psdk. In that case, csrss needs fixed to not block ReadConsoleInput() to line buffer. At 06:11 AM 5/4/2002 -0700, you wrote: >Hey all > >The console saga continues.. > >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. > >Futher up in the same file, in init_key, hConsoleInput is retrieved >as follows: >win32APICALL_HANDLE (hConsoleInput, GetStdHandle (STD_INPUT_HANDLE)); > >I'm really starting to doubt that the console is expected to be in >line mode by default... is that documented anywhere? > >- Jason |
|
From: Jason F. <jas...@ya...> - 2002-05-04 13:11:44
|
Hey all The console saga continues.. 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. Futher up in the same file, in init_key, hConsoleInput is retrieved as follows: win32APICALL_HANDLE (hConsoleInput, GetStdHandle (STD_INPUT_HANDLE)); I'm really starting to doubt that the console is expected to be in line mode by default... is that documented anywhere? - Jason __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com |
|
From: Jason F. <jas...@ya...> - 2002-05-04 11:51:54
|
Looks good to me, then finally this bug can die :)
Any objections?
- Jason
--- "KJK::Hyperion" <no...@li...> wrote:
> At 10.16 03/05/2002, you wrote:
> [...]
> >BUT _read (in msvcrt\io\read.c) doesn't want to return until it's
> read the
> >size requested (filebuf asks for 4096), even if enter is pressed
> [...]
>
> proposed patch for read.c (fixed logical flaw, general cleanup,
> added some
> comments. Some perplexities about the handling of carriage returns
> in text
> files):
>
> Index: io/read.c
> ===================================================================
> RCS file: /CVS/ReactOS/reactos/lib/msvcrt/io/read.c,v
> retrieving revision 1.4
> diff -u -r1.4 read.c
> --- io/read.c 1 Apr 2002 21:50:56 -0000 1.4
> +++ io/read.c 3 May 2002 20:03:46 -0000
> @@ -16,38 +16,49 @@
>
> size_t _read(int _fd, void *_buf, size_t _nbyte)
> {
> - DWORD _rbyte = 0, nbyte = _nbyte, count;
> - int cr;
> + DWORD _rbyte = 0, nbyte = _nbyte;
> char *bufp = (char*)_buf;
> + HANDLE hfile;
> + int istext;
>
> DPRINT("_read(fd %d, buf %x, nbyte %d)\n", _fd, _buf, _nbyte);
>
> - while (nbyte)
> + /* null read */
> + if(_nbyte == 0)
> + return 0;
> +
> + hfile = _get_osfhandle(_fd);
> + istext = __fileno_getmode(_fd) & O_TEXT;
> +
> + /* read data */
> + if (!ReadFile(hfile, bufp, nbyte, &_rbyte, NULL))
> {
> - if (!ReadFile(_get_osfhandle(_fd), bufp, nbyte, &_rbyte,
> NULL))
> - {
> - return -1;
> - }
> - if (_rbyte == 0)
> - break;
> - if (__fileno_getmode(_fd) & O_TEXT)
> + /* failure */
> + return -1;
> + }
> +
> + /* text mode */
> + if (_rbyte && istext)
> + {
> + int cr = 0;
> + DWORD count = _rbyte;
> +
> + /* repeat for all bytes in the buffer */
> + for(; count; bufp++, count--)
> {
> - cr = 0;
> - count = _rbyte;
> - while (count)
> - {
> - if (*bufp == '\r')
> - cr++;
> - else if (cr != 0)
> - *(bufp - cr) = *bufp;
> - bufp++;
> - count--;
> - }
> - _rbyte -= cr;
> - bufp -= cr;
> + /* carriage return */
> + if (*bufp == '\r')
> + cr++;
> + /* shift characters back, to ignore carriage returns */
> + else if (cr != 0)
> + *(bufp - cr) = *bufp;
> +
> }
> - nbyte -= _rbyte;
> +
> + /* ignore the carriage returns */
> + _rbyte -= cr;
> }
> - DPRINT("%d\n", _nbyte - nbyte);
> - return _nbyte - nbyte;
> +
> + DPRINT("%d\n", _rbyte);
> + return _rbyte;
> }
>
>
>
> _______________________________________________________________
>
> 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: David W. <we...@cw...> - 2002-05-04 11:07:09
|
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? |
|
From: Steven E. <ste...@ya...> - 2002-05-04 01:40:04
|
I'm still using lilo to dos then autoexec'd loadros. Once freeldr built with mingw works then I move to it now that freeldr can boot linux. Can I chain load freeldr to lilo? Steven --- Brian Palmer <br...@sg...> 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? > > Brian > __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com |
|
From: Brian P. <br...@sg...> - 2002-05-04 01:06:45
|
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? Brian |
|
From: Brian P. <br...@sg...> - 2002-05-04 00:45:03
|
Changes in v1.2.1 (5/3/2002)
- Makefile updates
- Optimized the Makefile
- Removed recursive make functionality (builds much faster now)
- Places all output into one single directory
- Added automagically generated dependencies
Modified Files:
CHANGELOG freeldr/Makefile
Added Files:
sed.exe freeldr/linuxboot.c freeldr/arch/i386/diskint13.S
freeldr/include/arch.h freeldr/include/cache.h
freeldr/include/comm.h freeldr/include/debug.h
freeldr/include/disk.h freeldr/include/freeldr.h
freeldr/include/fs.h freeldr/include/inifile.h
freeldr/include/linux.h freeldr/include/miscboot.h
freeldr/include/mm.h freeldr/include/multiboot.h
freeldr/include/options.h freeldr/include/oslist.h
freeldr/include/reactos.h freeldr/include/rtl.h
freeldr/include/ui.h freeldr/include/version.h
freeldr/inifile/ini_init.c freeldr/mm/mm_init.c
Removed Files:
freeldr/arch.h freeldr/cache.h freeldr/comm.h freeldr/debug.h
freeldr/disk.h freeldr/freeldr.h freeldr/fs.h
freeldr/inifile.h freeldr/linux.c freeldr/linux.h
freeldr/miscboot.h freeldr/mm.h freeldr/multiboot.h
freeldr/options.h freeldr/oslist.h freeldr/reactos.h
freeldr/rtl.h freeldr/rules.mk freeldr/ui.h freeldr/version.h
freeldr/arch/Makefile freeldr/arch/i386/Makefile
freeldr/arch/i386/disk.S freeldr/cache/Makefile
freeldr/comm/Makefile freeldr/disk/Makefile
freeldr/fs/Makefile freeldr/inifile/Makefile
freeldr/inifile/init.c freeldr/mm/Makefile freeldr/mm/init.c
freeldr/reactos/Makefile freeldr/rtl/Makefile
freeldr/ui/Makefile
|
|
From: KJK::Hyperion <no...@li...> - 2002-05-03 20:38:14
|
At 10.16 03/05/2002, you wrote:
[...]
>BUT _read (in msvcrt\io\read.c) doesn't want to return until it's read the
>size requested (filebuf asks for 4096), even if enter is pressed
[...]
proposed patch for read.c (fixed logical flaw, general cleanup, added some
comments. Some perplexities about the handling of carriage returns in text
files):
Index: io/read.c
===================================================================
RCS file: /CVS/ReactOS/reactos/lib/msvcrt/io/read.c,v
retrieving revision 1.4
diff -u -r1.4 read.c
--- io/read.c 1 Apr 2002 21:50:56 -0000 1.4
+++ io/read.c 3 May 2002 20:03:46 -0000
@@ -16,38 +16,49 @@
size_t _read(int _fd, void *_buf, size_t _nbyte)
{
- DWORD _rbyte = 0, nbyte = _nbyte, count;
- int cr;
+ DWORD _rbyte = 0, nbyte = _nbyte;
char *bufp = (char*)_buf;
+ HANDLE hfile;
+ int istext;
DPRINT("_read(fd %d, buf %x, nbyte %d)\n", _fd, _buf, _nbyte);
- while (nbyte)
+ /* null read */
+ if(_nbyte == 0)
+ return 0;
+
+ hfile = _get_osfhandle(_fd);
+ istext = __fileno_getmode(_fd) & O_TEXT;
+
+ /* read data */
+ if (!ReadFile(hfile, bufp, nbyte, &_rbyte, NULL))
{
- if (!ReadFile(_get_osfhandle(_fd), bufp, nbyte, &_rbyte, NULL))
- {
- return -1;
- }
- if (_rbyte == 0)
- break;
- if (__fileno_getmode(_fd) & O_TEXT)
+ /* failure */
+ return -1;
+ }
+
+ /* text mode */
+ if (_rbyte && istext)
+ {
+ int cr = 0;
+ DWORD count = _rbyte;
+
+ /* repeat for all bytes in the buffer */
+ for(; count; bufp++, count--)
{
- cr = 0;
- count = _rbyte;
- while (count)
- {
- if (*bufp == '\r')
- cr++;
- else if (cr != 0)
- *(bufp - cr) = *bufp;
- bufp++;
- count--;
- }
- _rbyte -= cr;
- bufp -= cr;
+ /* carriage return */
+ if (*bufp == '\r')
+ cr++;
+ /* shift characters back, to ignore carriage returns */
+ else if (cr != 0)
+ *(bufp - cr) = *bufp;
+
}
- nbyte -= _rbyte;
+
+ /* ignore the carriage returns */
+ _rbyte -= cr;
}
- DPRINT("%d\n", _nbyte - nbyte);
- return _nbyte - nbyte;
+
+ DPRINT("%d\n", _rbyte);
+ return _rbyte;
}
|
|
From: KJK::Hyperion <no...@li...> - 2002-05-03 20:01:05
|
At 10.16 03/05/2002, you wrote: > >not sure. Stdio FILE objects are supposed, AFAIK, to maintain their > >internal buffer, exactly to avoid the overhead of a system call to > >read a single character >I think you're right (btw wine's msvcrt functions call readconsole 1 char >at a time, so porting may be a bad idea after all). argh. Not only a system call, but a potential RPC call at each character read! [...] >BUT _read (in msvcrt\io\read.c) doesn't want to return until it's read the >size requested (filebuf asks for 4096), even if enter is pressed. So it >seems that's the problem. If we wanted buffered reading to limit system >call overhead, then _read must return if enter is pressed and the file in >use is stdin. What do you think about this? This behavior of read() is non-standard (I don't know if it's done for compatibility with Microsoft's CRT). A call to read() reading less than expected is still considered successful: "[...] If a read() is interrupted by a signal after it has successfully read some data, it will return the number of bytes read. [...]" |
|
From: Jason F. <jas...@ya...> - 2002-05-03 08:16:50
|
--- "KJK::Hyperion" <no...@li...> wrote: >not sure. Stdio FILE objects are supposed, AFAIK, to maintain their >internal buffer, exactly to avoid the overhead of a system call to >read a single character I think you're right (btw wine's msvcrt functions call readconsole 1 char at a time, so porting may be a bad idea after all). It's filbuf's job to send characters from stdin's buffer or perform a read if there's nothing in the buffer (which eventually calls readconsolea). BUT _read (in msvcrt\io\read.c) doesn't want to return until it's read the size requested (filebuf asks for 4096), even if enter is pressed. So it seems that's the problem. If we wanted buffered reading to limit system call overhead, then _read must return if enter is pressed and the file in use is stdin. What do you think about this? - Jason __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com |
|
From: David W. <we...@cw...> - 2002-05-02 23:52:43
|
On Tue, Apr 30, 2002 at 06:53:52PM +0200, Hartmut Birr wrote: > > Sometimes I see no stack frame, if there is a stack frame, it starts with > _irq_handler_0 and _irq_handler_14. On real hardware there isn't printed a > stack frame. > I've committed what is hopefully a fix for this problem. Part of the problem was that a very large structure (a TRAP_FRAME) was previously allocated on the stack in KiInterruptDispatch; this is a very bad idea in general. I also noticed that ide.sys seems to do a lot of work in its ISR and almost none in its DPC; could this be fixed? |
|
From: KJK::Hyperion <no...@li...> - 2002-05-02 21:36:43
|
At 10.29 02/05/2002, you wrote: >Ok the rational behind this fix: >- the console cannot be in line mode to get a single char (and return >immediately after, which is what getchar requires) not sure. Stdio FILE objects are supposed, AFAIK, to maintain their internal buffer, exactly to avoid the overhead of a system call to read a single character >- the console mode setting shouldn't be done in getc() or any lower >because they work with any kind of file (getchar is specific towards stdin) it shouldn't be done anywhere, mainly for thread safety |
|
From: Jason F. <jas...@ya...> - 2002-05-02 18:52:01
|
--- we...@cw... wrote: >I assume this is really a implementation for getch in which case it >is correct. I think these difficulties could be avoided by looking >at the WINE source code; it is available for browing on the web at >http://source.winehq.org and getch is >http://source.winehq.org/source/dlls/msvcrt/console.c#89 Ok I won't commit my own fix.. instead it looks like the best is to port wine's msvcrt code. As you said, it looks like that's the best way to avoid these problems. Thanks for the link! - Jason __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com |
|
From: Phillip S. <ps...@cf...> - 2002-05-02 11:05:57
|
I'll try to restate what I said before to clear this issue up. All standard C IO functions do NOT set the console to raw mode, they leave it line buffered. This means that gets and getchar, which it calls, will not process anything until the end of the line. Once the line ends, getchar() will return each char in the line, one at a time, each time it is called. No chars will be discarded, and only one will be returned at a time. The ONLY function that sets the console to raw mode is the non standard function getch(). All other functions in the C standard leave the console in line buffered mode. getchar() does NOT require that a char be gotten immediately, only that it reads a single char from stdin. At 01:29 AM 5/2/2002 -0700, you wrote: >Ok the rational behind this fix: >- the console cannot be in line mode to get a single char (and return >immediately after, which is what getchar requires) >- the console mode setting shouldn't be done in getc() or any lower >because they work with any kind of file (getchar is specific towards >stdin) > >Ok.. awaiting comments.. > >- Jason |
|
From: <we...@cw...> - 2002-05-02 09:30:00
|
Quoting Jason Filby <jas...@ya...>: > Ok the rational behind this fix: > - the console cannot be in line mode to get a single char (and return > immediately after, which is what getchar requires) > - the console mode setting shouldn't be done in getc() or any lower > because they work with any kind of file (getchar is specific towards > stdin) > > Ok.. awaiting comments.. > I assume this is really a implementation for getch in which case it is correct. I think these difficulties could be avoided by looking at the WINE source code; it is available for browing on the web at http://source.winehq.org and getch is http://source.winehq.org/source/dlls/msvcrt/console.c#89 |
|
From: Jason F. <ja...@gl...> - 2002-05-02 09:13:54
|
Did some work to get rid of two annoyances in the simple shell: o Implemented proper linespacing (after executing a command) o Implemented the cls command (ported from command.com) - Jason |
|
From: <we...@cw...> - 2002-05-02 09:10:13
|
Quoting Jason Filby <jas...@ya...>: > Ok I just want to ask a question to clear things up: > > If you tell ReadConsoleA to only read 1 character, will it return > upon reading that one characer - even if it's in line mode? Or must > you press enter, even though you only asked for 1? > > getc() only returns one character, so reading in an entire line is > useless. > IIRC ReadConsole will return only when a complete line is available (in ENABLE_LINE_INPUT mode) but only as many characters as asked for will be returned. Any remaining characters will be buffered internally. |
|
From: Jason F. <jas...@ya...> - 2002-05-02 08:29:21
|
Ok the rational behind this fix:
- the console cannot be in line mode to get a single char (and return
immediately after, which is what getchar requires)
- the console mode setting shouldn't be done in getc() or any lower
because they work with any kind of file (getchar is specific towards
stdin)
Ok.. awaiting comments..
- Jason
int
getchar(void)
{
int c;
DWORD oldStdinMode;
WINBOOL consoleResult, hadIONBF = FALSE;
HANDLE hStdin = _get_osfhandle(stdin->_file);
GetConsoleMode(hStdin, &oldStdinMode);
SetConsoleMode(hStdin, ENABLE_ECHO_INPUT | ENABLE_PROCESSED_INPUT);
if(!(stdin->_flag & _IONBF))
{
hadIONBF = TRUE;
stdin->_flag |= _IONBF;
}
c = getc(stdin);
if(hadIONBF)
{
stdin->_flag |= _IONBF;
}
SetConsoleMode(hStdin, oldStdinMode);
return c;
}
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
|
|
From: Jason F. <jas...@ya...> - 2002-05-02 07:18:21
|
Ok I just want to ask a question to clear things up: If you tell ReadConsoleA to only read 1 character, will it return upon reading that one characer - even if it's in line mode? Or must you press enter, even though you only asked for 1? getc() only returns one character, so reading in an entire line is useless. Thanks - Jason __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com |
|
From: Jason F. <jas...@ya...> - 2002-05-02 06:31:48
|
So you're saying that gets() should be calling getch() and not getchar()? - Jason --- Phillip Susi <ps...@cf...> wrote: > getc() and getchar() both do NOT set the terminal to raw mode, at > least not > on win2k with microsoft's msvcrt.dll. The non standard function > getch() > however, does, which also means that it returns special codes for > non ascii > keys, such as the arrow keys and function keys. None of the C > standard IO > functions will do this. > __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com |
|
From: Phillip S. <ps...@cf...> - 2002-05-01 23:55:19
|
getc() and getchar() both do NOT set the terminal to raw mode, at least not on win2k with microsoft's msvcrt.dll. The non standard function getch() however, does, which also means that it returns special codes for non ascii keys, such as the arrow keys and function keys. None of the C standard IO functions will do this. At 02:21 AM 5/2/2002 +0300, you wrote: >On Wed, 1 May 2002, Hartmut Birr wrote: > > > I think, getchar can not use getc for getting one character. Getchar must > > set the console to non line buffered mode, wait for one character and read > > it, and restore the old console mode. > > > > - Hartmut > >getchar(); should be equivalent to getc(stdin); It is getc() that has to >behave this way if its parameter is stdin and is redirected to the >keyboard. > > > Emil |
|
From: Kohn E. D. <em...@cs...> - 2002-05-01 23:21:14
|
On Wed, 1 May 2002, Hartmut Birr wrote: > I think, getchar can not use getc for getting one character. Getchar must > set the console to non line buffered mode, wait for one character and read > it, and restore the old console mode. > > - Hartmut getchar(); should be equivalent to getc(stdin); It is getc() that has to behave this way if its parameter is stdin and is redirected to the keyboard. Emil |
|
From: Eric K. <ek...@rz...> - 2002-05-01 21:51:54
|
Modified Files:
services/fs/cdfs/rw.c
services/fs/cdfs/volinfo.c
Implemented read support.
Disabled debug messages.
Todo:
- Caching.
- IRP queueing.
Now, CDs can be read!
Eric
|
|
From: Phillip S. <ps...@cf...> - 2002-05-01 21:05:52
|
Absolutely this change is not correct. ReadFile() reads the console in whatever mode it is set in currently. The CRT read() function, and all of the standard IO functions are not supposed to change the console mode, thus they will read line buffered. The console being line buffered would not cause gets() to fail, so I think you are barking up the wrong tree here. At 09:14 PM 5/1/2002 +0000, you wrote: >I don't see that the second change is correct; where is it documented that >ReadFile always reads in non-raw, echoed mode? Shouldn't the library >implementing the libc interface set the console mode themselves? |
|
From: David W. <we...@cw...> - 2002-05-01 20:31:31
|
On Wed, May 01, 2002 at 10:00:31PM +0200, Hartmut Birr wrote: > I make some test with gcc on ros. If I compile a large project (msvcrt from > ros), after some compiled files (>100) I get many messages from > ntoskrnl\mm\npool.c line 208 'previous c1145dcd' (or with other adresses > greater 0xc1000000). What does this mean? > Nothing. It is a debugging aid that for some reason wasn't removed. |
8 messages has been excluded from this view by a project administrator.
