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: Casper H. <ch...@us...> - 2002-05-15 22:45:30
|
ons, 2002-05-15 kl. 23:20 skrev Steven Edwards: > So where should bzip2, crtdll and msvcrt go? Shouldn't they stay with > the kernel? Bzip2 is for the ramdisk driver and I don't think we can use > wines crtdll/msvcrt. Oh yes, bzip2 is a kernel mode driver. How about moving it to services/lib? I forgot about the modules in apps/system/. IMO we should make these native applications and move them away from there. To subsys maybe? csrss is already there. If we make winlogon a native application we can have a unified logon system no matter which subsystems are installed. Of course, logon is still customizable by GINAs. |
|
From: KJK::Hyperion <no...@li...> - 2002-05-15 22:22:24
|
At 23.13 15/05/2002, you wrote: [...] >lib/bzip2 [...] >lib/zlib Not sure on these |
|
From: David W. <we...@cw...> - 2002-05-15 22:19:18
|
On Wed, May 15, 2002 at 11:13:23PM +0200, Casper Hornstrup wrote: > apps/* > lib/bzip2 > lib/crtdll > lib/dflat32 > lib/fmifs > lib/msvcrt > lib/ole32 > lib/oleaut32 > lib/psapi > lib/shell32 > lib/version > lib/zlib > subsys/os2/* > subsys/psx/* > apps/shell should be left but mingw32, rpcrt4 can be moved as well. |
|
From: Eric K. <ek...@rz...> - 2002-05-15 22:10:06
|
"Steven Edwards" <Ste...@ya...> wrote: > In reactos/lib we can remove Ole and ole32. I'm not 100% sure be we > might be able to use wines > Psapi and rpcrt. Eric can you comment? I'm sure we can use Wine's psapi. The rpcrt stuff might be a bit more difficult but it should usable too. Eric |
|
From: Steven E. <Ste...@ya...> - 2002-05-15 21:20:23
|
So where should bzip2, crtdll and msvcrt go? Shouldn't they stay with the kernel? Bzip2 is for the ramdisk driver and I don't think we can use wines crtdll/msvcrt. "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: Steven E. <Ste...@ya...> - 2002-05-15 21:16:48
|
In reactos/lib we can remove Ole and ole32. I'm not 100% sure be we might be able to use wines Psapi and rpcrt. Eric can you comment? Also you can rm -fr reactos/apps/tests. These were taken from the wine tree a long time back And wont be needed once we have the regression testing suite. Thanks 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: Wednesday, May 15, 2002 4:47 PM > To: rea...@li... > Subject: Re: [ros-kernel] Fwd: Reorganizing the cvs > repository before starting reactos.org > > > Ok which parts of win32 can we move out of ReactOS? > > - Jason > > --- Casper Hornstrup <ch...@us...> wrote: > > ons, 2002-05-15 kl. 13:46 skrev we...@cw...: > > > Quoting Casper Hornstrup <ch...@us...>: > > > > > > > > We will obviously never agree on this, so I suggest the > > following > > > > compromise. We flip some bits in the subsystem id field of the > > > > following low-level module images so they become native > > DLLs/applications: > > > > kernel32.dll, gdi32.dll, user32.dll, advapi32.dll, msafd.dll, > > > > ws2_32.dll, (csrss.exe, lsass.exe (already native apps in ROS > > btw.)), > > > > winlogon.exe and services.exe. Then we designate these as > > subsystem > > > > support modules and keep them in the reactos CVS module. If > > they are > > > > native, they can be used in any subsystem that wants to use > > them. > > > > > > > This is all that I am suggesting anyway; perhaps in any case > > restrictions > > > on executables of one subsystem using the dlls of another should > > just > > > be removed. > > > > I am okay with native <-> subsystem dependencies (*), but not with > > subsystem <-> subsystem dependencies, because it encourages > developers > > to create subsystems that depend on other subsystems. If this > > happens, > > then you loose a bit of flexibility to customize your distribution > > (one > > reason why companies like linux so much). If there are modules that > > are > > generic enough to be used in several subsystems, then we should IMO > > distribute them with the reactos module as native modules that any > > subsystem can use. This way, a subsystem can depend on the module > > always > > beeing installed on a ReactOS distribution. > > > > * -> only if the dependancy is optional. For instance ws2_32.dll > > supports Winsock service providers and should be able to > use existing > > service providers written for the Win32 API. Another example is > > services.exe which should be able to execute in-process services > > (like > > the usere-mode PnP manager) that belong to any subsystem. > > > > > > > > _______________________________________________________________ > > > > 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!? > LAUNCH - Your Yahoo! Music Experience > http://launch.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: Casper H. <ch...@us...> - 2002-05-15 21:16:11
|
ons, 2002-05-15 kl. 22:46 skrev Jason Filby: > Ok which parts of win32 can we move out of ReactOS? > > - Jason IMO, the following should be moved out of the reactos module: apps/* lib/bzip2 lib/crtdll lib/dflat32 lib/fmifs lib/msvcrt lib/ole32 lib/oleaut32 lib/psapi lib/shell32 lib/version lib/zlib subsys/os2/* subsys/psx/* I think we should eventually dump the DLLs that are also in WINE and use the WINE versions instead. |
|
From: Jason F. <jas...@ya...> - 2002-05-15 20:47:15
|
Ok which parts of win32 can we move out of ReactOS? - Jason --- Casper Hornstrup <ch...@us...> wrote: > ons, 2002-05-15 kl. 13:46 skrev we...@cw...: > > Quoting Casper Hornstrup <ch...@us...>: > > > > > > We will obviously never agree on this, so I suggest the > following > > > compromise. We flip some bits in the subsystem id field of the > > > following low-level module images so they become native > DLLs/applications: > > > kernel32.dll, gdi32.dll, user32.dll, advapi32.dll, msafd.dll, > > > ws2_32.dll, (csrss.exe, lsass.exe (already native apps in ROS > btw.)), > > > winlogon.exe and services.exe. Then we designate these as > subsystem > > > support modules and keep them in the reactos CVS module. If > they are > > > native, they can be used in any subsystem that wants to use > them. > > > > > This is all that I am suggesting anyway; perhaps in any case > restrictions > > on executables of one subsystem using the dlls of another should > just > > be removed. > > I am okay with native <-> subsystem dependencies (*), but not with > subsystem <-> subsystem dependencies, because it encourages > developers > to create subsystems that depend on other subsystems. If this > happens, > then you loose a bit of flexibility to customize your distribution > (one > reason why companies like linux so much). If there are modules that > are > generic enough to be used in several subsystems, then we should IMO > distribute them with the reactos module as native modules that any > subsystem can use. This way, a subsystem can depend on the module > always > beeing installed on a ReactOS distribution. > > * -> only if the dependancy is optional. For instance ws2_32.dll > supports Winsock service providers and should be able to use > existing > service providers written for the Win32 API. Another example is > services.exe which should be able to execute in-process services > (like > the usere-mode PnP manager) that belong to any subsystem. > > > > _______________________________________________________________ > > 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!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: Eric K. <ek...@rz...> - 2002-05-15 20:25:34
|
Modified Files:
services/fs/cdfs/cdfs.c
services/fs/cdfs/fsctl.c
services/fs/fs_rec/blockdev.c
services/fs/fs_rec/cdfs.c
services/fs/fs_rec/fat.c
services/fs/fs_rec/fs_rec.c
services/fs/fs_rec/fs_rec.h
services/fs/fs_rec/ntfs.c
services/fs/vfat/cleanup.c
services/fs/vfat/close.c
services/fs/vfat/create.c
services/fs/vfat/iface.c
Added experimental support for FAT and NTFS FSDs.
Silenced debug messges.
Eric
|
|
From: Jason F. <jas...@ya...> - 2002-05-15 20:08:21
|
Sorry, my mistake, the MX record of reactos.com is not yet corrected. Hang in there.. - Jason __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: Jason F. <jas...@ya...> - 2002-05-15 19:40:28
|
Hey all Thanks to Phillip Susi's friend, Eric Katanich, we now have hosting for out lists again at an @reactos.com address again. So you can begin using the old lists as per usual again. The lists are: ros...@re... ro...@re... ros...@re... ros...@re... Those using the SourceForge lists (kernel), please move discussions back to ros...@re.... - Jason __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: Eric K. <ek...@rz...> - 2002-05-15 13:08:49
|
"Hartmut Birr" <har...@te...> wrote: > Some times ago, I've tested vfatfs on NT. The mount procedure from vfatfs > results in a BSOD. I've changed some lines in VfatMount (vfat/fsctl.c) for > NT. > > #ifdef __VFAT_NT__ > DeviceExt->StorageDevice = > IrpContext->Stack->Parameters.Mount.DeviceObject; > DeviceExt->StorageDevice->Vpb->DeviceObject = DeviceObject; > DeviceExt->StorageDevice->Vpb->RealDevice = DeviceExt->StorageDevice; > DeviceExt->StorageDevice->Vpb->Flags |= VPB_MOUNTED; > DeviceObject->StackSize = DeviceExt->StorageDevice->StackSize + 1; > DeviceObject->Flags &= ~DO_DEVICE_INITIALIZING; > #else > DeviceObject->Vpb->Flags |= VPB_MOUNTED; > DeviceExt->StorageDevice = IoAttachDeviceToDeviceStack(DeviceObject, > IrpContext->Stack->Parameters.Mount.DeviceObject); > #endif Ahh! Changing the stack size might be the answer to my problem. The other free file system drivers don't seem to increment the stack size. I'll try this when I'm done with the file system recognizer driver. Eric |
|
From: Eric K. <ek...@rz...> - 2002-05-15 13:08:49
|
"David Welch" <we...@cw...> wrote: > I think someone with the appropiate hardware should test comparable > changes. Is ReactOS multiprocessor support still being maintained? Once I tried to run MP-ReactOS on my Dual-P III board, but I couldn't even build it without trouble. IIRC, it crashed while initializing the second CPU. I didn't investigate this. Eric |
|
From: Casper H. <ch...@us...> - 2002-05-15 12:27:01
|
ons, 2002-05-15 kl. 13:46 skrev we...@cw...: > Quoting Casper Hornstrup <ch...@us...>: > > > > We will obviously never agree on this, so I suggest the following > > compromise. We flip some bits in the subsystem id field of the > > following low-level module images so they become native DLLs/applications: > > kernel32.dll, gdi32.dll, user32.dll, advapi32.dll, msafd.dll, > > ws2_32.dll, (csrss.exe, lsass.exe (already native apps in ROS btw.)), > > winlogon.exe and services.exe. Then we designate these as subsystem > > support modules and keep them in the reactos CVS module. If they are > > native, they can be used in any subsystem that wants to use them. > > > This is all that I am suggesting anyway; perhaps in any case restrictions > on executables of one subsystem using the dlls of another should just > be removed. I am okay with native <-> subsystem dependencies (*), but not with subsystem <-> subsystem dependencies, because it encourages developers to create subsystems that depend on other subsystems. If this happens, then you loose a bit of flexibility to customize your distribution (one reason why companies like linux so much). If there are modules that are generic enough to be used in several subsystems, then we should IMO distribute them with the reactos module as native modules that any subsystem can use. This way, a subsystem can depend on the module always beeing installed on a ReactOS distribution. * -> only if the dependancy is optional. For instance ws2_32.dll supports Winsock service providers and should be able to use existing service providers written for the Win32 API. Another example is services.exe which should be able to execute in-process services (like the usere-mode PnP manager) that belong to any subsystem. |
|
From: <we...@cw...> - 2002-05-15 11:46:09
|
Quoting Casper Hornstrup <ch...@us...>: > > We will obviously never agree on this, so I suggest the following > compromise. We flip some bits in the subsystem id field of the > following low-level module images so they become native DLLs/applications: > kernel32.dll, gdi32.dll, user32.dll, advapi32.dll, msafd.dll, > ws2_32.dll, (csrss.exe, lsass.exe (already native apps in ROS btw.)), > winlogon.exe and services.exe. Then we designate these as subsystem > support modules and keep them in the reactos CVS module. If they are > native, they can be used in any subsystem that wants to use them. > This is all that I am suggesting anyway; perhaps in any case restrictions on executables of one subsystem using the dlls of another should just be removed. |
|
From: Casper H. <ch...@us...> - 2002-05-15 11:14:51
|
ons, 2002-05-15 kl. 01:56 skrev David Welch: > On Tue, May 14, 2002 at 11:14:16PM +0200, Aliberti Emanuele wrote: > > My proposal to split the source tree in > > > > reactos > > w32 > > psx > > os2 > > ... > > > > was only to clean "the layout of files" before the games turns big, > > not to say Win32 isn't the main environment subsystem of ReactOS. > > > Right but the layout ought to reflect that win32 and the kernel are not > really seperated; at least the system dlls (kernel32, user32, gdi32, > advapi32), csrss and the security system should stay with the reactos > module. We will obviously never agree on this, so I suggest the following compromise. We flip some bits in the subsystem id field of the following low-level module images so they become native DLLs/applications: kernel32.dll, gdi32.dll, user32.dll, advapi32.dll, msafd.dll, ws2_32.dll, (csrss.exe, lsass.exe (already native apps in ROS btw.)), winlogon.exe and services.exe. Then we designate these as subsystem support modules and keep them in the reactos CVS module. If they are native, they can be used in any subsystem that wants to use them. It might also be easier to develop new subsystems, because the Win32 API is a lot easier to work with than the native API. I included msafd.dll and ws2_32.dll in the list because it will be a lot easier to support a sockets API in a subsystem this way. I included services.exe because it provides functionality that you would expect from any OS (services) and also because it is tightly integrated with advapi32.dll (service API). |
|
From: Eric K. <ek...@rz...> - 2002-05-15 09:44:39
|
Modified Files:
ntoskrnl/include/internal/io.h
ntoskrnl/io/buildirp.c
ntoskrnl/io/create.c
ntoskrnl/io/fs.c
bootc.lst
install.bat
Makefile
system.hiv
Added Files:
services/fs/fs_rec/.cvsignore
services/fs/fs_rec/blockdev.c
services/fs/fs_rec/cdfs.c
services/fs/fs_rec/fat.c
services/fs/fs_rec/fs_rec.c
services/fs/fs_rec/fs_rec.h
services/fs/fs_rec/fs_rec.rc
services/fs/fs_rec/makefile
services/fs/fs_rec/ntfs.c
- Added file system recognizer driver.
- Implemented file system driver loading.
- Minor cleanup.
Note: Currently the file system recognizer driver supports only CDFS.
Eric
|
|
From: Jason F. <jas...@ya...> - 2002-05-15 08:20:44
|
--- David Welch <we...@cw...> wrote: >Right but the layout ought to reflect that win32 and the kernel are >not really seperated; at least the system dlls (kernel32, user32, >gdi32, advapi32), csrss and the security system should stay with the >reactos module. Why not move out GUI related/higher level DLLs at least, that is, DLLs that are mainly ported from Wine (as Steven suggested)? This is unnecessary code for coders working on other subsystems and makes porting back and forth between Wine easier. - Jason __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: Jason F. <jas...@ya...> - 2002-05-15 08:15:32
|
Cool! :) Just don't quote me on that where a system doesn't have a design yet ;) - Jason --- "KJK::Hyperion" <no...@li...> wrote: > At 01.24 15/05/2002, you wrote: > >That's great! :) What's up next for POSIX+? > > First I need to investigate the getpid/getppid inconsistency. Then > I'll > have a look at existing functions to see if they run correctly in a > fork() > child, and see if also static variables are copy-on-write (I have > some > suspects). After I'm sure that fork() works without side effects, > I'll > implement exec(). Then I'll help Emanuele with the subsystem, to > get > signals working and minimal support for virtual terminals. After > that, > POSIX+ will be fully functional for single-threaded programs. It > will > "only" just need stdio and a bunch of miscellaneous functions to be > usable > > PS: I remeber you said to the FreeOS team something like: "here's > what I > learned working on ReactOS: don't be timid, write code as soon as > possible, > or you'll get stuck". Well, it's how it worked for me today :-) > > > _______________________________________________________________ > > 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!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com |
|
From: Yuri P. <pro...@fr...> - 2002-05-15 05:00:24
|
On Wed, 15 May 2002 01:53:23 +0200, KJK::Hyperion wrote: >At 06.27 15/05/2002, you wrote: >> >I consider win32k.sys as part of the Windows NT executive architecture >> >and not part of the Win32 subsystem. Therefore I believe win32k.sys >> >should be in the reactos module. I however, see no reason for building >> >the Win32 subsystem if you are not developing or distributing this part, >> >so the Win32 subsystem should go in it's own module. >>I agree. All subsystems kernel parts _must_ be represented as kernel part. >>Any subsystem allows use any kernel part of subsystems. Any subsystem's >>kernel extensions >>must be native part of reactos. >I don't agree. If I'll ever write the POSIX kernel extensions - and this >may surprise those that believe that I want to make ReactOS "yet another >Unix" - I'll never try to sneak them into the main tree: I realize that >POSIX signals (the main, if not sole purpose of POSIX kernel extensions) >are *hardly* to be considered part of an NT kernel (ok, I *do* believe that >a system is handicapped if it doesn't implement signals) Ok. If subsystems kernel extension used more than by one subsystem then this extension must be moved to kernel and interpreted as kernel part but not subsystem part. |
|
From: Patrick M. <ox...@st...> - 2002-05-15 05:00:23
|
On Wed, May 15, 2002 at 01:33:11AM +0200, KJK::Hyperion wrote: > ... that I forgot to ask: > - is there some --do-exactly-what-i-say-and-not-what-you-think-i-need > switch? because no matter how many -no this and -fno that I put in the > command line, if a program happens to have a procedure called main, a big, > annoying static library is linked to the executable, adding an unnecessary doesn't "gcc -nostartfiles" work (probably with -nostdlibs or something like that? if not, it seems you have found a bug in the gcc-win32 port as that is how it should work... patrick mauritz -- ,------------------------------------------------------------------------. > In the Beginning there was nothing, which exploded - Yeah right... < |------------------------------------------------------------------------| > Moonlight 3D Resurrected | www.moonlight3d.net < `------------------------------------------------------------------------' Your right to swing your fist ends where my nose begins |
|
From: Steven E. <Ste...@ya...> - 2002-05-15 01:39:29
|
Irc.openprojects.net "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 James Tabor > Sent: Tuesday, May 14, 2002 9:19 PM > To: rea...@li... > Subject: Re: [ros-kernel] Fwd: Reorganizing the cvs > repository before starting reactos.org > > > Steven Edwards wrote: > > > > Are you still online? If so jump on #reactos > > > > > Yeah. were is #reactos? > James > > _______________________________________________________________ > > 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: Steven E. <Ste...@ya...> - 2002-05-15 01:25:10
|
Alex wont accept these because it's a mingw problem not wines. You will need these to shut up some nasty warning/errors. cvs diff -u windef.h Index: windef.h =================================================================== RCS file: /home/wine/wine/include/windef.h,v retrieving revision 1.63 diff -u -r1.63 windef.h --- windef.h 1 May 2002 18:13:19 -0000 1.63 +++ windef.h 15 May 2002 01:22:04 -0000 @@ -149,6 +149,9 @@ #endif #endif /* NOMINMAX */ +#ifdef __MINGW__ +#undef MAX_PATH +#endif #define MAX_PATH 260 #define HFILE_ERROR ((HFILE)-1) *****CVS exited normally with code 1***** cvs diff -u basetsd.h Index: basetsd.h =================================================================== RCS file: /home/wine/wine/include/basetsd.h,v retrieving revision 1.4 diff -u -r1.4 basetsd.h --- basetsd.h 10 Mar 2002 00:02:34 -0000 1.4 +++ basetsd.h 15 May 2002 01:22:43 -0000 @@ -44,7 +44,9 @@ typedef char __int8; typedef short __int16; typedef int __int32; +#ifndef __MINGW__ typedef long long __int64; +#endif #endif /* !defined(_MSC_VER) */ typedef unsigned char __uint8; @@ -91,11 +93,13 @@ /* Always signed and 64 bit wide */ +#ifndef __MINGW__ typedef __int64 LONG64; typedef __int64 INT64; typedef LONG64 *PLONG64; typedef INT64 *PINT64; +#endif /* Always unsigned and 64 bit wide */ |
|
From: James T. <jim...@ad...> - 2002-05-15 01:18:45
|
Steven Edwards wrote: > > Are you still online? If so jump on #reactos > > Yeah. were is #reactos? James |
|
From: Steven E. <Ste...@ya...> - 2002-05-15 01:17:17
|
> I thought doing that in wine was a NO! NO! That is what Alex > posted a year ago! James It is, but there have been a few limited cases where he has broken his own rules. Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
8 messages has been excluded from this view by a project administrator.
