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: Jason F. <jas...@ya...> - 2002-07-10 20:16:25
|
Small steps are best - they usually lead to things getting done in the end. A more NT-architecture-friendly WINE would really help us guys working on ReactOS! - Jason --- Eric Pouech <eri...@wa...> wrote: > > IMHO the way WINE handles certain things is really > > fubar. > basically, since Wine evolves like Windows did (16 bit => > win32 à la Win9x => NT infra), wine suffers from the same > defaults :-( > > however, I agree with you that spreading wineserver calls > all over the DLLs is a bad idea > IMO, the ultimate design would be to only have wineserver > calls in NTDLL, but that's a long way to go... > it would permit nice things as: > - portability on windows for testing the various DLLs > - (should be good for ReactOS) > - would allow to resign drop in replacement for NTDLL, like > moving (part of) wineserver inside the Linux kernel > - ... > > to start with, I think keeping the wineserver calls only > in the holy three DLLs should be an acceptable short term > target > > BTW, I did extend a bit the PSAPI implementation (for some > missing API) and was also upset by the calls to toolhelp > for that > > in short, moving to NT architecture is the way to go, but > it'll need some time > may be we could also create a metabug on bugzilla for this > and link all known issues to this meta-bug. > > A+ > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Two, two, TWO treats in one. > http://thinkgeek.com/sf > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: Steven E. <ste...@ya...> - 2002-07-10 20:12:41
|
This is a mingw bug....they were supposed to fix it in the current cvs as I sent them a patch but they wanted to stick it in some #ifdef wrapper for older broken mingw apps so i dunno if it was ever accepted or now. I dunno support brokeness IMHO is just wrong and it is pain....they should just make whoever fix thier code if it depends on this as it is wrong in MS_VC anyway. Feel free to voice your comments to them Steven --- "KJK::Hyperion" <no...@li...> wrote: > At 08.34 09/07/2002, you wrote: > >Is everyone who has been testing still getting > this? > > why did stdlib.h define MAX_PATH, anyway? > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Two, two, TWO treats in one. > http://thinkgeek.com/sf > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: David W. <we...@cw...> - 2002-07-10 20:05:27
|
On Wed, Jul 10, 2002 at 07:49:31PM +0200, Eric Kohl wrote: > > When I type "Make install", it creates that directory and starts putting > > files there :( > > "Make install" is broken and should not be used. Use install.bat (DOS/Win) > or install.sh (Linux) instead. > 'make install' works on Linux, install.sh just copies the reactos subdirectory to the final destination. |
|
From: David W. <we...@cw...> - 2002-07-10 20:05:26
|
On Wed, Jul 10, 2002 at 08:50:35PM +0200, KJK::Hyperion wrote: > I'll jump on the bandwagon... they should copy and check parameters, and > check permissions, only if ExGetPreviousMode == KernelMode. I read this on > NTDEV months ago, and I waited for the occasion to say it :-) > MmCopyToCaller/MmCopyFromCaller should already do the right thing for the value of previous mode; they also encapsulate the checks that the caller can legally access the address in question. |
|
From: David W. <we...@cw...> - 2002-07-10 20:05:25
|
On Wed, Jul 10, 2002 at 05:24:08PM +0200, Eric Kohl wrote: > ntoskrnl/ps/create.c > ntoskrnl/ps/suspend.c > Implemented the ability to create suspended threads. > I don't understand this patch. Why create the wait blocks explicitly? Also has the suspend/resume functionality been tested? |
|
From: David W. <we...@cw...> - 2002-07-10 20:05:25
|
On Wed, Jul 10, 2002 at 08:43:42PM +0200, KJK::Hyperion wrote: > what are these two for? I've never heard them > Win9X rubbish IIRC. |
|
From: KJK::Hyperion <no...@li...> - 2002-07-10 19:45:56
|
At 09.50 10/07/2002, you wrote: >Very few kernel functions use these two functions. Most just use >parameters directly, some don't even check for NULL pointers. I'll jump on the bandwagon... they should copy and check parameters, and check permissions, only if ExGetPreviousMode == KernelMode. I read this on NTDEV months ago, and I waited for the occasion to say it :-) >Any volunteers to go through the functions that are exported by kernel and >fix this problem? I think I can. It doesn't sound hard. Do you have ICQ? |
|
From: KJK::Hyperion <no...@li...> - 2002-07-10 19:45:50
|
At 18.09 10/07/2002, Royce Mitchell III wrote: > > touch drivers/lib/zlib/zlib.sym works for me. >Doesn't the file have to exist before I can touch it? nope. Touch should create it |
|
From: KJK::Hyperion <no...@li...> - 2002-07-10 19:45:50
|
At 08.15 09/07/2002, you wrote: >MapSL >ConvertToGlobalHandle what are these two for? I've never heard them >PSAPI I'm (was) working on PSAPI, but it's obviously based on the NT API. The module enumeration (not done yet - I have to dig down the LDR structures) will require a memory layout that matches NT's down to the byte - specifically, all processes must have a PEB, and it must be exactly identical to NT's. I think the Wine guys should better keep their toolhelp-based implementation. It's an especially "delicate" area |
|
From: KJK::Hyperion <no...@li...> - 2002-07-10 19:45:46
|
At 08.14 10/07/2002, you wrote: [...] >How do I get it to create the SYM file? fixing the tools/helper.mk file. We don't have a rule for symbol files of static libraries. zlib just happens to be our one and only static library |
|
From: KJK::Hyperion <no...@li...> - 2002-07-10 19:45:37
|
At 08.34 09/07/2002, you wrote: >Is everyone who has been testing still getting this? why did stdlib.h define MAX_PATH, anyway? |
|
From: Eric K. <ek...@rz...> - 2002-07-10 17:45:37
|
"Royce Mitchell III" <ro...@ev...> wrote: > Is there supposed to be a "C:\Reactos\Reactos"? No, it is not! > When I type "Make install", it creates that directory and starts putting > files there :( "Make install" is broken and should not be used. Use install.bat (DOS/Win) or install.sh (Linux) instead. Eric |
|
From: Royce M. I. <ro...@ev...> - 2002-07-10 16:14:15
|
> touch drivers/lib/zlib/zlib.sym works for me. Doesn't the file have to exist before I can touch it? make -C drivers/lib/zlib install make[1]: *** No rule to make target `zlib.sym', needed by `../../../reactos/system32/zlib.a'. Stop. make[1]: Entering directory `C:/reactos/drivers/lib/zlib' make[1]: Leaving directory `C:/reactos/drivers/lib/zlib' C:\MINGW\BIN\MAKE.EXE: *** [zlib_install] Error 2 |
|
From: Royce M. I. <ro...@ev...> - 2002-07-10 15:30:21
|
Is there supposed to be a "C:\Reactos\Reactos"? When I type "Make install", it creates that directory and starts putting files there :( |
|
From: Eric K. <ek...@rz...> - 2002-07-10 15:19:35
|
ntoskrnl/include/ps.h
ntoskrnl/kd/gdbstub.c
ntoskrnl/ke/thread.c
ntoskrnl/ke/i386/irq.c
ntoskrnl/ps/thread.c
Renamed some thread states.
ntoskrnl/ps/create.c
ntoskrnl/ps/suspend.c
Implemented the ability to create suspended threads.
lib/kernel32/file/npipe.c
ConnectNamedPipe(): STATUS_PIPE_CONNECTED reports a successful connect.
Eric
|
|
From: Steven E. <ste...@ya...> - 2002-07-10 14:31:37
|
> in short, moving to NT architecture is the way to > go, but > it'll need some time > may be we could also create a metabug on bugzilla > for this > and link all known issues to this meta-bug. I will start a meta bug for this and being to track these issues as I find them. With any luck we will be able to help with these issues in the next few months. Steven __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: Eric P. <eri...@wa...> - 2002-07-10 12:07:56
|
> IMHO the way WINE handles certain things is really > fubar.=20 basically, since Wine evolves like Windows did (16 bit =3D> win32 =E0 la Win9x =3D> NT infra), wine suffers from the same defaults :-( however, I agree with you that spreading wineserver calls all over the DLLs is a bad idea IMO, the ultimate design would be to only have wineserver calls in NTDLL, but that's a long way to go... it would permit nice things as: - portability on windows for testing the various DLLs - (should be good for ReactOS) - would allow to resign drop in replacement for NTDLL, like moving (part of) wineserver inside the Linux kernel - ... to start with, I think keeping the wineserver calls only in the holy three DLLs should be an acceptable short term target BTW, I did extend a bit the PSAPI implementation (for some missing API) and was also upset by the calls to toolhelp for that in short, moving to NT architecture is the way to go, but it'll need some time may be we could also create a metabug on bugzilla for this and link all known issues to this meta-bug. A+ |
|
From: <we...@cw...> - 2002-07-10 09:07:43
|
Quoting Royce Mitchell III <ro...@ev...>: > make -C drivers/lib/zlib install > make[1]: *** No rule to make target `zlib.sym', needed by > `../../../reactos/syst > em32/zlib.a'. Stop. > make[1]: Entering directory `C:/reactos/drivers/lib/zlib' > make[1]: Leaving directory `C:/reactos/drivers/lib/zlib' > C:\MINGW\BIN\MAKE.EXE: *** [zlib_install] Error 2 > > Apparently the SYM files are not being generated. Here is what I've > done: > > make clean > make > make install << this is where the above error appears > > How do I get it to create the SYM file? > touch drivers/lib/zlib/zlib.sym works for me. |
|
From: Steven E. <ste...@ya...> - 2002-07-10 09:02:40
|
can you send me your stdlib.h from a windows mingw install. Mine my be hosed and I want to double check before committing this patch. --- James Tabor <jim...@ad...> wrote: > Steven Edwards wrote: > > > > Is everyone who has been testing still getting > this? > > If so I have a patch that I think will fix it. > > > > Steven > > > Hi, > Yes, it is annoying but I can live with it. If you > do have > a patch, go ahead and post it. > Thanks, > James > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Stuff, things, and much much more. > http://thinkgeek.com/sf > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: Eugene I. <ge...@my...> - 2002-07-10 07:50:04
|
I hope I'm not missing something, but I think there is a problem with our kernel code. AFAIK, all the kernel functions that may be called from user mode have to use MmCopyFromCaller to copy all the function arguments safely into kernel space and then use MmCopyToCaller to copy them back. Basically it prevents user code from crashing the kernel by passing bogus parameters. Very few kernel functions use these two functions. Most just use parameters directly, some don't even check for NULL pointers. Guys, it's much easier to program these things right then to debug them later. Any volunteers to go through the functions that are exported by kernel and fix this problem? ei |
|
From: Royce M. I. <ro...@ev...> - 2002-07-10 06:19:24
|
make -C drivers/lib/zlib install make[1]: *** No rule to make target `zlib.sym', needed by `../../../reactos/syst em32/zlib.a'. Stop. make[1]: Entering directory `C:/reactos/drivers/lib/zlib' make[1]: Leaving directory `C:/reactos/drivers/lib/zlib' C:\MINGW\BIN\MAKE.EXE: *** [zlib_install] Error 2 Apparently the SYM files are not being generated. Here is what I've done: make clean make make install << this is where the above error appears How do I get it to create the SYM file? Royce3 |
|
From: James T. <jim...@ad...> - 2002-07-09 23:52:49
|
Steven Edwards wrote: > > Is everyone who has been testing still getting this? > If so I have a patch that I think will fix it. > > Steven > Hi, Yes, it is annoying but I can live with it. If you do have a patch, go ahead and post it. Thanks, James |
|
From: David K. <kr...@mb...> - 2002-07-09 06:37:19
|
Dplayx is now OK, but shell32:
gcc -Wl,--base-file,base.tmp \
-Wl,--entry,_DllMain@12 \
-mdll -Wl,--image-base,0x76090000 \
-o junk.tmp \
../../ole/uuid.o brsfolder.o changenotify.o classes.o clipboard.o
control.o dataobject.o debughlp.o dialogs.o enumidlist.o folders.o iconcach
e.o memorystream.o pidl.o shell32_main.o shelllink.o shlmenu.o shellole.o
shellord.o shellpath.o shellstring.o shellreg.o shlexec.o shlfileop.o shlfol
der.o shlview.o shpolicy.o shv_bg_cmenu.o shv_item_cmenu.o systray.o
shell32.dll.dbg.o ../../../reactos/dk/w32/lib/ntdll.a
../../../reactos/dk/w32/lib
/kernel32.a ../../../reactos/dk/w32/lib/advapi32.a
../../../reactos/dk/w32/lib/gdi32.a ../../../reactos/dk/w32/lib/user32.a
../../../reactos/dk/w32/li
b/comctl32.a ../../../reactos/dk/w32/lib/ole32.a
../../../reactos/dk/w32/lib/shlwapi.a
../../../reactos/dk/w32/lib/wine_unicode.a ../../../reactos/dk/
w32/lib/libwine.a
shell32_main.o(.text+0x3ef5):shell32_main.c: undefined reference to
`MapSL@4'
make[1]: *** [shell32.nostrip.dll] Error 1
make[1]: Leaving directory `d:/ros/wine/dlls/shell32'
make: *** [shell32] Error 2
|
|
From: Steven E. <ste...@ya...> - 2002-07-09 06:34:22
|
Is everyone who has been testing still getting this? If so I have a patch that I think will fix it. Steven __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
|
From: Steven E. <ste...@ya...> - 2002-07-09 06:15:50
|
Note: Forwarded to wine-devel I'm more in support of us chaning wine rather then adapting win9x calls to ReactOS. That being said I have enough trouble writing a 3 line patch so my voice doesnt count to much..."You guys are the programmers, I just break shit." IMHO the way WINE handles certain things is really fubar. A good example besides MapSL and ConvertToGlobalHandle is the way WINE implements PSAPI. All wine psapi does it convert the toolhelp functions already implemented in to the needed format with a wineserver call or two thrown in. If we are going to use wine and not fork the crap out of it then we should fix the 9xisms as we find them. Currently wine has all sorts of ways for doing things, you have win16 apis being called in some places, ntdll in others and then 9xisms all over the place. So far we have MapSL ConvertToGlobalHandle PSAPI DriectX HAL interfaces ? idunno I guess it comes to what can we do to better share code. Currently there is not a chance in hell of us sharing PSAPI in its current state. I started two bugs in wines bugzilla a few weeks ago regarding it. Mabey we should have a meta-bug for making WINE more NT like in "certain" areas. I dont expect the wine projects to make all sorts of changes just for us and not as they are trying to get a 1.0 release. Anyone got any feedback? Mabey we will get more support for this once David and Jason are done with the basic Windowing. Steven > MapSL is in wine kernel32 also, Oh yeah, it's part > of windows 9x > kernel32.dll too. > James __________________________________________________ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com |
8 messages has been excluded from this view by a project administrator.
