Menu
▾
▴
reactos-kernel
|
From: Eric K. <ek...@rz...> - 2002-05-01 13:15:54
|
Added files:
services/fs/cdfs/misc.c
Modified files:
services/fs/cdfs/cdfs.h
services/fs/cdfs/close.c
services/fs/cdfs/create.c
services/fs/cdfs/dirctl.c
services/fs/cdfs/fcb.c
services/fs/cdfs/finfo.c
services/fs/cdfs/fsctl.c
services/fs/cdfs/makefile
Fixed FCB management functions.
Added file and directory information.
Fixed several minor bugs.
Disabled most debug messages.
Eric
|
|
From: Eric K. <ek...@rz...> - 2002-05-09 15:52:02
|
Modified Files:
services\fs\cdfs\cdfs.h
services\fs\cdfs\common.c
services\fs\cdfs\create.c
services\fs\cdfs\dirctl.c
services\fs\cdfs\fcb.c
services\fs\cdfs\fsctl.c
services\fs\cdfs\misc.c
services\fs\cdfs\rw.c
Added file and directory caching.
Improved verify support.
Fixed a joliet filename bug.
Eric
|
|
From: Eric K. <ek...@rz...> - 2002-05-14 23:16:04
|
Modified files:
services/fs/cdfs/cdfs.c
services/fs/cdfs/dirctl.c
services/fs/cdfs/fcb.c
services/fs/cdfs/fsctl.c
services/fs/cdfs/rw.c
Fixed several cache-related bugs.
Silenced debug messages.
Eric
|
|
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: 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: Eric K. <ek...@rz...> - 2002-05-22 15:53:55
|
Modified files:
system.hiv
subsys/smss/init.c
subsys/smss/smss.c
subsys/smss/smss.h
Read settings from the registry.
Eric
|
|
From: Eric K. <ek...@rz...> - 2002-05-23 09:51:49
|
Modified files:
ntoskrnl/io/create.c
services/fs/cdfs/fsctl.c
services/fs/ext2/super.c
services/fs/minix/mount.c
services/fs/template/template.c
services/fs/vfat/fsctl.c
Log message:
Use NT-compatible (VPB-based) mounting mechanism.
Eric
|
|
From: Eric K. <ek...@rz...> - 2002-05-24 07:52:26
|
New files:
apps/system/autochk/autochk.c
apps/system/autochk/autochk.rc
apps/system/autochk/makefile
Modified files:
install.bat
Makefile
ntoskrnl/cm/import.c
ntoskrnl/io/fs.c
subsys/smss/init.c
subsys/smss/smapi.c
subsys/smss/smss.c
subsys/smss/smss.h
Messgage log:
Added import of REG_EXPAND_SZ registry values.
Added media change support.
Added 'BootExecute'-feature to smss.
Added autochk dummy application.
Eric
|
|
From: Eric K. <ek...@rz...> - 2002-05-24 18:06:20
|
Modified files:
ntoskrnl/cm/rtlfunc.c
lib/ntdll/rtl/registry.c
subsys/smss/init.c
system.hiv
Message log:
Fixed a severe bug in RtlQueryRegistryValues() and implemented support for
REG_EXPAND_SZ.
Read the system environment from the registry.
Eric
|
|
From: Eric K. <ek...@rz...> - 2002-05-25 13:37:20
|
Modified files:
include/ntos/disk.h
ntoskrnl/io/xhaldrv.c
services/storage/atapi/atapi.c
services/storage/cdrom/cdrom.c
services/storage/class2/class2.c
services/storage/disk/disk.c
services/storage/include/ntddscsi.h
services/storage/scsiport/scsiport.c
Message log:
Made NTFS-Partitions mountable.
Fixed timeout for unpopulated ide channels.
Fixed inquiry data block for unpopulated ide channels.
Minor cleanup.
Eric
|
|
From: Eric K. <ek...@rz...> - 2002-05-26 20:25:41
|
Modified files:
ntoskrnl/io/xhaldrv.c
services/storage/atapi/atapi.c
services/storage/cdrom/cdrom.c
services/storage/class2/class2.c
services/storage/scsiport/scsiport.c
Log message:
Silenced debug messages.
Implemented command retries.
Improved error handling.
Enabled drive letter assignment to removable drives.
Always update a drive's geometry data.
Eric
|
|
From: Hartmut B. <har...@te...> - 2002-05-27 18:22:24
|
subsys\smss\init.c: Fixed creation of paging file in SmPagingFilesQueryRoutine. lib\kernel32\file\file.c: Fixed returned file length in GetFileInformationByHandle. - Hqartmut |
|
From: Eric K. <ek...@rz...> - 2002-05-28 09:51:54
|
services/fs/vfat/fsctl.c
Fix to support removable media (512 bytes per sector only!).
services/stoarge/disk/disk.c
Build a fake partition table for removable media drives.
services/storage/atapi/atapi.c
Wait for BUSY to clear prior to selecting a drive. Disabled old code.
These changes enable the use of removable media devices such as MO (230Mb
disks tested) and Zip drives. To support larger disks, such as 640Mb or
1.3Gb MO disks, the vfat driver needs to support 1024 byte and 2048 byte
sectors.
Eric
|
|
From: Casper H. <ch...@us...> - 2002-05-28 22:41:53
|
I have some time to do a cleanup of our code base. Is everyone using the latest MinGW release (gcc-3.1, w32api-1.4) ? If not, please upgrade soon. I will throw out our old Windows API headers and use MinGW whereever possible to have better code sharing with WINE. I will start reorganizing CVS like we discussed on this list. Any last words, before I begin? - Casper |
|
From: Steven E. <Ste...@ya...> - 2002-05-29 00:33:35
|
> Any last words, before I begin? Good Riddance =P We still need to write the shell script for doing a import of the wine makefiles and use the winebuild system. Currently we can use winebuild to generate the *.defs we need.We can also use the wine resource compiler so we don't have to fork the wine resources. What you have to do is first feed the wine resources to wrc then feed the output of that to windres. ONE MORE TIME - If anyone is feeling frisky and wants to help on my WINE work email me already. So what is the final outline for strucure of our cvs tree? This is the way I think we have it but I want to double check. This is by no means a compleate outline. CVSROOT - -freeldr -rodocs -reactos.org -reactos -lib -tools -apps -ntoskrnl -services -hal -include -rosapps -sysutils -net -misc -win32 (wine tree + certain moved reactos/lib modules) -include -dlls -tools -programs ? -psx -include ? -React/OS2 =) -include -apps ? Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: KJK::Hyperion <no...@li...> - 2002-05-29 05:53:44
|
At 02.33 29/05/2002, you wrote: >ONE MORE TIME - If anyone is feeling frisky and wants to help on my WINE >work email me already. Sorry, I'd help, but I always try to avoid anything involving shell scripts :-( >So what is the final outline for strucure of our cvs tree? This is the way >I think we have it but I want to double check. This is by no means a >compleate outline. Perfect |
|
From: Steven E. <Ste...@ya...> - 2002-05-29 06:26:01
|
> At 02.33 29/05/2002, you wrote: > >ONE MORE TIME - If anyone is feeling frisky and wants to help on my > >WINE > >work email me already. > > Sorry, I'd help, but I always try to avoid anything involving > shell scripts :-( All that is really needed is "something" that 1. Runs ./configure 2. Converts the Makefiles. It could be a small c program that parses the Makefiles and imports them in to reactos makefiles. I really don't care at this point, hell even bringing out the ducktape and using Perl would be fine as it wont be part of the standard build process. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: Diego I. <ias...@ac...> - 2002-05-30 19:47:20
|
I am ready, hopefuly they are online somewhere. did you get my last email? - diego On Wednesday 29 May 2002 09:26, Steven Edwards wrote: > > At 02.33 29/05/2002, you wrote: > > >ONE MORE TIME - If anyone is feeling frisky and wants to help on my > > >WINE > > >work email me already. > > > > Sorry, I'd help, but I always try to avoid anything involving > > shell scripts :-( > > All that is really needed is "something" that > > 1. Runs ./configure > 2. Converts the Makefiles. > > It could be a small c program that parses the Makefiles and imports them > in to reactos makefiles. I really don't care at this point, hell even > bringing out the ducktape and using Perl would be fine as it wont be > part of the standard build process. > > Thanks > Steven > > "Every revolution was once a thought in one man's mind" > - Ralph Waldo Emerson > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel -- October 12, the Discovery. It was wonderful to find America, but it would have been more wonderful to miss it. -- Mark Twain, "Pudd'nhead Wilson's Calendar" |
|
From: Casper H. <ch...@us...> - 2002-05-29 14:08:16
|
ons, 2002-05-29 kl. 02:33 skrev Steven Edwards: > So what is the final outline for strucure of our cvs tree? This is the > way I think we have it but I want to double check. This is by no means a > compleate outline. > > CVSROOT - > -win32 (wine tree + certain moved reactos/lib modules) > -include > -dlls > -tools > -programs > ? > > Thanks > Steven Are we keeping WINE in our CVS? When WINE compiles with MinGW, we really don't need to have any ReactOS specific modifications to it, so it would be better to checkout a copy of WINE from the WINE CVS instead. Then there is no need to synchronize two modules. |
|
From: Robert K. <ro...@ko...> - 2002-05-29 18:53:32
|
I think keeping wine is superfluous. We'd rather establish a dynamic import and patch process. What about the OS2 sub system? It'll get its own module- OK. Who will do this? When? What will be the name? How can I reach it? Is it still CVS? Shall I establish my own build process? Casper Hornstrup schrieb: > ons, 2002-05-29 kl. 02:33 skrev Steven Edwards: > > So what is the final outline for strucure of our cvs tree? This is the > > way I think we have it but I want to double check. This is by no means a > > compleate outline. > > > > CVSROOT - > > -win32 (wine tree + certain moved reactos/lib modules) > > -include > > -dlls > > -tools > > -programs > > ? > > > > Thanks > > Steven > > Are we keeping WINE in our CVS? When WINE compiles with MinGW, we really > don't need to have any ReactOS specific modifications to it, so it would > be better to checkout a copy of WINE from the WINE CVS instead. Then > there is no need to synchronize two modules. > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel |
|
From: Eric K. <ek...@rz...> - 2002-05-29 19:59:03
|
"Casper Hornstrup" <ch...@us...> wrote: > I have some time to do a cleanup of our code base. Is everyone using the > latest MinGW release (gcc-3.1, w32api-1.4) ? If not, please upgrade > soon. I will throw out our old Windows API headers and use MinGW > whereever possible to have better code sharing with WINE. > > I will start reorganizing CVS like we discussed on this list. > > Any last words, before I begin? Are you going to replace our current DDK headers too? I noticed that our current code uses the PTxxx partition type constants (propably taken from linux) instead of PARTITION_xxxx constants. I'd like to fix that before you start cleaning up the mess. ;-) Eric |
|
From: Casper H. <ch...@us...> - 2002-05-29 20:33:37
|
ons, 2002-05-29 kl. 22:00 skrev Eric Kohl: > > "Casper Hornstrup" <ch...@us...> wrote: > > > > I have some time to do a cleanup of our code base. Is everyone using the > > latest MinGW release (gcc-3.1, w32api-1.4) ? If not, please upgrade > > soon. I will throw out our old Windows API headers and use MinGW > > whereever possible to have better code sharing with WINE. > > > > I will start reorganizing CVS like we discussed on this list. > > > > Any last words, before I begin? > > Are you going to replace our current DDK headers too? Not at first. I'll do this when I've submitted the Windows XP DDK to MinGW and gotten some feedback. I expect there to be some issues with packing. Then I'll have to add enough obsoleted Windows NT 4.0 structures so we can move over to this DDK. So in short, it will probably be at least a month before we can do this. > I noticed that our current code uses the PTxxx partition type constants > (propably taken from linux) instead of PARTITION_xxxx constants. I'd like to > fix that before you start cleaning up the mess. ;-) > > Eric Oh, it would be nice if you could fix such compatibility issues when you spot them. It will make the transition easier ;o) Another issue is, when we use w32api and winddk from MinGW, how do we handle additions to those? We can submit patches to MinGW, but when our code base depends on these additions, then ReactOS developers must use the latest w32api and winddk from CVS in order to compile. Of course, we can try to batch such additions in order to minimize the number of upgrades necesarry. - Casper |
|
From: Eric K. <ek...@rz...> - 2002-05-29 21:46:12
|
"Casper Hornstrup" <ch...@us...> wrote: > Oh, it would be nice if you could fix such compatibility issues when you > spot them. It will make the transition easier ;o) Done! :-) > Another issue is, when we use w32api and winddk from MinGW, how do we > handle additions to those? We can submit patches to MinGW, but when our > code base depends on these additions, then ReactOS developers must use > the latest w32api and winddk from CVS in order to compile. Of course, we > can try to batch such additions in order to minimize the number of > upgrades necesarry. The only way to avoid any problems of this kind is to keep our own header files and import libraries (SDK and DDK). We'd have to sync them with MinGW every now and then. Even if we use the latest w32api and winddk from CVS, it will always take a while until a patch gets checked into the MinGW tree. Until then, the ReactOS CVS tree and the MinGW CVS tree will be out of sync. We'll have to avoid this. Eric |
|
From: Rex J. <re...@lv...> - 2002-05-29 01:23:49
|
At 12:34 AM 5/29/02 +0200, you wrote: >I have some time to do a cleanup of our code base. Is everyone using the >latest MinGW release (gcc-3.1, w32api-1.4) ? If not, please upgrade >soon. I will throw out our old Windows API headers and use MinGW >whereever possible to have better code sharing with WINE. > >I will start reorganizing CVS like we discussed on this list. > >Any last words, before I begin? If the reorganization of the repository is going to involve a large number of files, we can backdoor it by moving directories in the repository. This of course will break old versions, which may not be a problem, but the version history will be preserved. Of course the ideal approach is to move the files the cvs way, that is, with add/remove pairs for each file and a commit with a reasonable commit indicating the move. Rex Jolliff re...@lv... |
|
From: Jason F. <jas...@ya...> - 2002-05-29 07:29:55
|
I vote for the backdoor approach, since a lot of files will be moved. I don't think it matters where they used to be. I've got a complete listing of what needs to be moved, I'll mail that to the list tonight. - Jason --- Rex Jolliff <re...@lv...> wrote: > At 12:34 AM 5/29/02 +0200, you wrote: > >I have some time to do a cleanup of our code base. Is everyone > using the > >latest MinGW release (gcc-3.1, w32api-1.4) ? If not, please > upgrade > >soon. I will throw out our old Windows API headers and use MinGW > >whereever possible to have better code sharing with WINE. > > > >I will start reorganizing CVS like we discussed on this list. > > > >Any last words, before I begin? > > If the reorganization of the repository is going to involve a large > number of files, we can backdoor it by moving directories in the > repository. This of course will break old versions, which may not > be a problem, but the version history will be preserved. Of course > the ideal approach is to move the files the cvs way, that is, with > add/remove pairs for each file and a commit with a reasonable > commit indicating the move. > > > Rex Jolliff > re...@lv... > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- > http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X