Menu
▾
▴
reactos-kernel
|
From: Rex J. <re...@lv...> - 2002-05-30 01:08:51
|
At 07:13 PM 5/28/02 -0700, you wrote: >Maybe we can switch to a better revision control system. There was an >article on slashdot about bitkeeper. It has a strange status (not open >source), but it is used for linux kernel. I have looked at other revision control systems in the past, and didn't find any that meets my needs for free. There is ClearCase if you want the Cadillac of such systems, but its a burden to configure and maintain, not to mention real pricey. CVS has been around a long time and is solid and meets our needs. It has the limitation that it cannot track movement of files, and I agree this is a nasty limitation to have, but we can live with it, as Jason or I will do the bulk moves needed to satisfy the new layout. I really don't have time to acquire, install, configure and maintain a new revision control system these days, I still haven't even found time to setup cvsup for Brian (I'll try this weekend, honest :-)). So, unless I hear some very compelling arguments for another system, my vote is to stay with CVS. Rex Jolliff re...@lv... |
|
From: Casper H. <ch...@us...> - 2002-05-30 02:50:36
|
tor, 2002-05-30 kl. 03:09 skrev Rex Jolliff:
> At 07:13 PM 5/28/02 -0700, you wrote:
> >Maybe we can switch to a better revision control system. There was an
> >article on slashdot about bitkeeper. It has a strange status (not open
> >source), but it is used for linux kernel.
>
> I have looked at other revision control systems in the past, and didn't
> find any that meets my needs for free. There is ClearCase if you want the
> Cadillac of such systems, but its a burden to configure and maintain,
> not to mention real pricey. CVS has been around a long time and is
> solid and meets our needs. It has the limitation that it cannot track
> movement of files, and I agree this is a nasty limitation to have, but
> we can live with it, as Jason or I will do the bulk moves needed to
> satisfy the new layout.
>
> I really don't have time to acquire, install, configure and maintain a
> new revision control system these days, I still haven't even found time
> to setup cvsup for Brian (I'll try this weekend, honest :-)). So, unless
> I hear some very compelling arguments for another system, my vote
> is to stay with CVS.
>
>
> Rex Jolliff
> re...@lv...
CVS is great...when compared to having no version control system. This
does not mean it cannot be improved upon. Some features I would like to
see in a version control system includes:
* Atomicity and scalable. CVS uses many locks.
* Versioned directories, renames, and moves.
* Able to do more offline. Eg. the diffs used for the last
update could be cached.
* Easier repeated merging. A pain to do with CVS. You have to be very
careful.
* Better handling of binary files.
* Fewer conlicts. Some smart person could probably figure out how to
achieve this.
* Extensible through plugins. To allow for greater customization.
* Per module/directory/file access control.
* Issue tracking system integration. Eg. if I commit a patch with a
log message containing the tags "@issue ros10 @status fixed", then
the issue tracking system would be notified that the issue with ID
"ros10" should have status "fixed".
* Delayed transactions. If I wanted to ensure that a project at least
compiles after a patch is committed, then the transaction could be
put in a delayed state and then an external program is run to apply
the patch and then try to compile the project. If the compile is
successful then the transaction can be committed. If not, then
transaction is rolled back. This could be used with a regression
framework too, thereby achieving a more stable code base.
* Able to exclude certain paths from a working copy. Eg. for this
particular working copy I only need /dir1 and /dir2 but not
/dir1/subdir1 so don't update them when I update the working copy.
* Assign meta data to files and directories. Versioned of course.
* Symbolic links. Cross repository symlinks too. OSS projects tend to
depend on each other so why not have a symlink in a repository
pointing to a path in another projects repository? Then you would
only need one URL as the version control system could transparently
follow symlinks to the other repositories.
- Casper
|
|
From: Iain S. <iai...@me...> - 2002-05-30 17:08:00
|
On 5/29/02 6:09 PM, "Rex Jolliff" <re...@lv...> wrote: > At 07:13 PM 5/28/02 -0700, you wrote: >> Maybe we can switch to a better revision control system. There was an >> article on slashdot about bitkeeper. It has a strange status (not open >> source), but it is used for linux kernel. > > I have looked at other revision control systems in the past, and didn't > find any that meets my needs for free. There is ClearCase if you want the > Cadillac of such systems, but its a burden to configure and maintain, > not to mention real pricey. CVS has been around a long time and is > solid and meets our needs. It has the limitation that it cannot track > movement of files, and I agree this is a nasty limitation to have, but > we can live with it, as Jason or I will do the bulk moves needed to > satisfy the new layout. A non-open source but free to open source projects alternative is perforce (www.perforce.com). This is a commercial VCS that is simple, crossplatform, powerful and fast fast fast. The server is pretty much zero-administration. It comes with a feature which lets you create trouble tickets (jobs) and then associate them with changes so submissions close them. You can customize jobs to serve as a nice, lightweight bug tracking system, or use their API to integrate with other bug tracking systems (they already have a free module to integrate with bugzilla). You can move or rename files while retaining history across these changes, etc etc etc. The OpenWatcom.org project is using it and the watcom compiler project may be a great partner for reactos (ming always feels like a poor second cousin to a native windows compiler)... Anyhow, just a suggestion. -iain |
|
From: Casper H. <ch...@us...> - 2002-05-30 17:58:51
|
tor, 2002-05-30 kl. 18:47 skrev Iain Shigeoka: > On 5/29/02 6:09 PM, "Rex Jolliff" <re...@lv...> wrote: > > The OpenWatcom.org project is using it and the watcom compiler project may > be a great partner for reactos (ming always feels like a poor second cousin > to a native windows compiler)... > > Anyhow, just a suggestion. We have several advantages when using/supporting only gcc/binutils. they are present on a lot of platforms. This means less work for us when we expand to these platforms. By supporting only one compiler we don't have to be so strict about about following every standard out there or have workarounds for missing features of other compilers. We can use gcc specific features because we know they are there. If you look at binutils and gcc projects which must compile with many different compilers and versions of those, you will see that there are many guidelines that must be followed when submitting patches to these projects. This is one reason (of many), that it is difficult to get patches into these projects. GCC is not just a C/C++ compiler. It is designed to have "plugin" frontends written for it to support many languages. When the GPC frontend is included in the official releases, there really is no valid reasons left for keeping Pascal programmers away from ReactOS anymore. - Casper |
|
From: KJK::Hyperion <no...@li...> - 2002-05-31 17:36:41
|
At 19.51 30/05/2002, you wrote: >We have several advantages when using/supporting only gcc/binutils. they >are present on a lot of platforms. This means less work for us when we >expand to these platforms. >By supporting only one compiler we don't have to be so strict about >about following every standard out there or have workarounds for missing >features of other compilers. [...] Dangerous attitude. While it's ok to have compiler-specific *code*, at least the headers shouldn't be |
|
From: Eugene I. <ge...@my...> - 2002-05-29 02:12:58
|
Maybe we can switch to a better revision control system. There was an article on slashdot about bitkeeper. It has a strange status (not open source), but it is used for linux kernel. I don't know much about rcs, so don't kill me. Comments? ei ----- Original Message ----- From: "Rex Jolliff" <re...@lv...> To: <rea...@li...> Sent: Tuesday, May 28, 2002 6:24 PM Subject: Re: [ros-kernel] Cleanup > 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 > |
|
From: Steven E. <Ste...@ya...> - 2002-05-29 03:45:36
|
> Maybe we can switch to a better revision control system. > There was an article on slashdot about bitkeeper. It has a > strange status (not open source), but it is used for linux kernel. I would like to stick with cvs just because it will make importing a fork of WINE easy. Thanks Steven "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson |
|
From: Casper H. <ch...@us...> - 2002-05-29 14:19:36
|
ons, 2002-05-29 kl. 05:45 skrev Steven Edwards: > > Maybe we can switch to a better revision control system. > > There was an article on slashdot about bitkeeper. It has a > > strange status (not open source), but it is used for linux kernel. > > I would like to stick with cvs just because it will make importing a > fork of WINE easy. > > Thanks > Steven > > "Every revolution was once a thought in one man's mind" > - Ralph Waldo Emerson Importing files should be no more difficult with another version control system. You just use "cvs export <module>" with CVS and use whatever is needed to import files using the other version control system. I have been monitoring the progress of subversion (http://subversion.tigris.org). I have set up a read/write test site at http://reactos.wox.org:7000/svn/reactos. If anyone want to try it out, go to subversion.tigris.org and grab a client. Then use "svn co http://reactos.wox.org:7000/svn/reactos" to checkout a copy. - Casper |
|
From: Eugene I. <ge...@my...> - 2002-05-29 02:17:34
|
Watcom compiler has been released as open source software. http://www.openwatcom.org Anyone brave enough to try to compile reactos with it? :) ei |
|
From: KJK::Hyperion <no...@li...> - 2002-05-29 05:53:43
|
At 04.18 29/05/2002, you wrote: >Watcom compiler has been released as open source software. >http://www.openwatcom.org >Anyone brave enough to try to compile reactos with it? :) Maybe I'll try. Just to see if it's at least compatible with binutils (Borland C++ isn't, since it outputs OMF, instead of COFF, object files. But all I need is a Turbo Assembler compatible assembler that outputs COFF). I want to make headers compatible, at least |
|
From: Patrick M. <ox...@st...> - 2002-05-30 07:15:43
|
On Thu, May 30, 2002 at 04:43:20AM +0200, Casper Hornstrup wrote: > CVS is great...when compared to having no version control system. This > does not mean it cannot be improved upon. Some features I would like to > see in a version control system includes: ok, let's compare subversion (aka. SVN, http://subversion.tigris.org) and arch (www.regexps.com) against your wishes, both are free > * Atomicity and scalable. CVS uses many locks. - SVN+Arch: atomic commits - commit the whole set or nothing of it revisions are per-change, not per-change-of-file > * Versioned directories, renames, and moves. - SVN: versioned source tree, renames and moved explicitely (svn cp, svn mv...) - Arch: same as SVN, but also supports file tags for renames and moves (ie. have "tag: some_unique_identifier" in the file header and this file _is_ unique with no special attention to be taken for the VCS) > * Able to do more offline. Eg. the diffs used for the last > update could be cached. - SVN+Arch: a complete original tree is present on the local box, in .svn or {arch} which is used for diffs etc > * Easier repeated merging. A pain to do with CVS. You have to be very > careful. what exactly do you mean by this? > * Better handling of binary files. Arch takes care of this for sure, I think SVN does as well (dunno) > * Fewer conlicts. Some smart person could probably figure out how to > achieve this. by using something more sensible than diff/patch? maybe - but I don't know such a thing (except for the sccs-format maybe) > * Extensible through plugins. To allow for greater customization. - SVN: can be configured for that - Arch: doesn't support it for a reason: a respository should work for everyone without having to care for client side extensions (there is no real "server") > * Per module/directory/file access control. on module-boundaries: does even exist with CVS, needs server access the other things: why? either you want to give access to the source or you don't > * Issue tracking system integration. Eg. if I commit a patch with a > log message containing the tags "@issue ros10 @status fixed", then > the issue tracking system would be notified that the issue with ID > "ros10" should have status "fixed". - SVN: I guess they'll do something like that (compare: scarab.tigris.org which is a sibling-project) - Arch: again, I guess sth. like that will be done - this time it's called labnotes > * Delayed transactions. If I wanted to ensure that a project at least > compiles after a patch is committed, then the transaction could be > put in a delayed state and then an external program is run to apply > the patch and then try to compile the project. If the compile is > successful then the transaction can be committed. If not, then > transaction is rolled back. This could be used with a regression > framework too, thereby achieving a more stable code base. why can't you do this on your own box? > * Able to exclude certain paths from a working copy. Eg. for this > particular working copy I only need /dir1 and /dir2 but not > /dir1/subdir1 so don't update them when I update the working copy. - that could work with CVS, but not with SVN or Arch as both of them always do versioning over the whole tree, not over single files > * Assign meta data to files and directories. Versioned of course. - SVN has full metadata support (ie. put any junk you want into it) - Arch supports filesystem metadata > * Symbolic links. Cross repository symlinks too. OSS projects tend to > depend on each other so why not have a symlink in a repository > pointing to a path in another projects repository? Then you would > only need one URL as the version control system could transparently > follow symlinks to the other repositories. - SVN+Arch: internal symlinks should be supported - Arch: as you can branch (with the ability to merge forth and back) over server boundaries (as strictly speaking there is no "server") that can be done easily as long as the other project is also arch-controlled some further description to arch (eg. why I insist that there is no server): arch is designed to work on a local directory as repository which is enhanced by some "virtual file system"-library which maps normal access to ftp transparently for that process. there are patches to map onto sftp, webdav and rsync as well, iirc. after creating a local repository, you can branch off a remote one and work (with full versioning) in your local repo with the ability to merge new patchsets from the original place to the new one and back. so it's not as there aren't any free VCS except CVS, it's just that they're quite new and not yet in the 1.0 stage... sincerely, patrick mauritz -- ,------------------------------------------------------------------------. > In the Beginning there was nothing, which exploded - Yeah right... < |------------------------------------------------------------------------| > The Forthcoming OpenBIOS | www.freiburg.linux.de/openbios < `------------------------------------------------------------------------' Understanding yourself without understanding your enemy only gives you half a chance of victory |
|
From: Casper H. <ch...@us...> - 2002-05-30 12:01:41
|
tor, 2002-05-30 kl. 09:14 skrev Patrick Mauritz:
> On Thu, May 30, 2002 at 04:43:20AM +0200, Casper Hornstrup wrote:
> > * Easier repeated merging. A pain to do with CVS. You have to be very
> > careful.
> what exactly do you mean by this?
If you have one branch (say TRUNK), create another branch (say
BRANCH), and then later want to merge all changes made on TRUNK after
BRANCH was created to BRANCH. This will CVS do just fine. Now, when you
next time perform the merge again (+ all never changes on TRUNK), then
CVS will not remember that you have already merged some of the changes
to BRANCH and you will have a lot of conflicts. To avoid this with CVS,
you can tag the TRUNK branch when you do a merge and then merge changes
from the last tag you made (or the branch point the first time) to the
new tag. If you forget to tag TRUNK, you are out of luck; prepare
yourself for conflicts.
> > * Extensible through plugins. To allow for greater customization.
> - SVN: can be configured for that
> - Arch: doesn't support it for a reason: a respository should work
> for everyone without having to care for client side extensions
> (there is no real "server")
Well, I don't believe in the idea of software that is so good that it
can be used for any purpose.
>
> > * Per module/directory/file access control.
> on module-boundaries: does even exist with CVS, needs server access
> the other things: why? either you want to give access to the source
> or you don't
You might give read access for some to an area, and read/write access to
another.
>
> > * Delayed transactions. If I wanted to ensure that a project at least
> > compiles after a patch is committed, then the transaction could be
> > put in a delayed state and then an external program is run to apply
> > the patch and then try to compile the project. If the compile is
> > successful then the transaction can be committed. If not, then
> > transaction is rolled back. This could be used with a regressioYn
> > framework too, thereby achieving a more stable code base.
> why can't you do this on your own box?
You can - and should, but for some reason it does not work on large
projects. If you monitor the WINE and Subversion bug lists, you will
notice that there are regularly regressions in their projects (and it is
arrogant to say that we don't have them -- we just have no way of
immediately spotting them -- yet). We can say that the regressions are
there because these projects have bad software engineers, but I choose
to believe it is because the tools that are used, does very little to
help keep regressions out of the code base.
Today we have only two configurations, but still we have sometimes had
code in CVS that would not compile. Bad programmers or human
limitations? Do you want to spend half an hour, doing a clean build of
ReactOS in these two configurations after each little patch you've
created? What will happen when ReactOS is ported to many more platforms?
I doubt it will be any easier to do manually so why not set up a box to
take care of such things?
>
> > * Able to exclude certain paths from a working copy. Eg. for this
> > particular working copy I only need /dir1 and /dir2 but not
> > /dir1/subdir1 so don't update them when I update the working copy.
> - that could work with CVS, but not with SVN or Arch as both of them
> always do versioning over the whole tree, not over single files
Still, the client could choose to ignore some paths.
|
|
From: Eric K. <ek...@rz...> - 2002-05-29 21:40:03
|
Modified files:
include/ntos/disk.h
ntoskrnl/io/xhaldrv.c
services/fs/vfat/fsctl.c
Message log:
Replaced linux partiton type constants. Kept them as reference.
Eric
|
|
From: Eric K. <ek...@rz...> - 2002-06-04 13:47:27
|
Modified files:
ntoskrnl/include/internal/se.h
ntoskrnl/se/semgr.c
ntoskrnl/se/token.c
Log message:
Fixed token type initialization.
Eric
|
|
From: Eric K. <ek...@rz...> - 2002-06-06 16:19:05
|
lib/ntdll/rtl/dos8dot3.c
ntoskrnl/rtl/dos8dot3.c
Fixed a typo in RtlGenerate8dot3Name().
Added more tests to RtlIsNameLegalDOS8Dot3().
drivers/fs/cdfs/cdfs.h
drivers/fs/cdfs/dirctl.c
Added partial suppport for short names (8.3 names).
Eric
|
|
From: Eric K. <ek...@rz...> - 2002-06-06 23:17:52
|
drivers/storage/cdrom/cdrom.c
drivers/storage/class2/class2.c
drivers/storage/disk/disk.c
drivers/storage/scsiport/scsiport.c
Fixed broken handling of SCSI port capabilities.
Eric
|
|
From: Hartmut B. <har...@te...> - 2002-06-07 16:50:58
|
kernel32\file\file.c: Fixed the return value in GetFileSize. drivers\fs\vfat\fsctl.c: Fixed the allocation size for the fat in VfatMount. - Hartmut |
|
From: Eric K. <ek...@rz...> - 2002-06-07 20:10:57
|
system.hiv include/defines.h ntoskrnl/ldr/loader.c subsys/system/services/database.c (new) subsys/system/services/makefile subsys/system/services/services.c subsys/system/services/services.h (new) Let services.exe load the auto-start drivers. Eric |
|
From: Joseph G. <gal...@va...> - 2002-06-08 03:55:53
|
> system.hiv > include/defines.h > ntoskrnl/ldr/loader.c > subsys/system/services/database.c (new) > subsys/system/services/makefile > subsys/system/services/services.c > subsys/system/services/services.h (new) > > Let services.exe load the auto-start drivers. I'm having trouble booting into bochs since I got this change. (Well, I'm not sure it was this change, but I didn't see anything else.) No drivers will load. For example, I get: Loading keyboard.sys... (ldr/loader.c:1017) LdrLoadModule() failed (ldr/loader.c:375) Driver load failed, status (c0000001) Further investigation reveals that IopCreateFile() is failing because the parent is of type directory, not device. Eventually, the system bug-checks after trying to load ndis.sys. (Bug check code 0.) I get a stack trace and then another bug check, this time 0x1d. I'm not quite sure where to go from here. - Joseph |
|
From: Casper H. <ch...@us...> - 2002-06-08 22:35:00
|
l=F8r, 2002-06-08 kl. 05:55 skrev Joseph Galbraith: > > system.hiv > > include/defines.h > > ntoskrnl/ldr/loader.c > > subsys/system/services/database.c (new) > > subsys/system/services/makefile > > subsys/system/services/services.c > > subsys/system/services/services.h (new) > >=20 > > Let services.exe load the auto-start drivers. >=20 > I'm having trouble booting into bochs since I > got this change. (Well, I'm not sure it was > this change, but I didn't see anything else.) >=20 > No drivers will load. For example, I get: >=20 > Loading keyboard.sys... > (ldr/loader.c:1017) LdrLoadModule() failed > (ldr/loader.c:375) Driver load failed, status (c0000001) >=20 > Further investigation reveals that IopCreateFile() > is failing because the parent is of type directory, > not device. >=20 > Eventually, the system bug-checks after trying to > load ndis.sys. (Bug check code 0.) I get a stack > trace and then another bug check, this time 0x1d. >=20 > I'm not quite sure where to go from here. >=20 > - Joseph I can confirm this. Freeldr does not load any boot drivers when using the new version of system.hiv. When using an older system.hiv it works okay. - Casper |
|
From: Eric K. <ek...@rz...> - 2002-06-09 00:46:54
|
"Joseph Galbraith" <gal...@va...> wrote: > I'm having trouble booting into bochs since I > got this change. (Well, I'm not sure it was > this change, but I didn't see anything else.) Are you booting with FreeLoader or Loadros (boot.bat)? I just checked out a clean tree, built it and booted it using Loadros. Runs fine! With the last patch I changed the format of the 'group order list' from semi-colon separated value string (REG_SZ) to multi string (REG_SZ_MULTI). LoadRos doesn't handle this properly yet. I'll fix it tomorrow as soon as I'm out of bed and had my first coffee. ;-) > No drivers will load. For example, I get: > > Loading keyboard.sys... > (ldr/loader.c:1017) LdrLoadModule() failed > (ldr/loader.c:375) Driver load failed, status (c0000001) Looks like the disk drivers aren't loaded. > Further investigation reveals that IopCreateFile() > is failing because the parent is of type directory, > not device. > > Eventually, the system bug-checks after trying to > load ndis.sys. (Bug check code 0.) I get a stack > trace and then another bug check, this time 0x1d. Eric |
|
From: Joseph G. <gal...@va...> - 2002-06-10 14:42:59
|
> > I'm having trouble booting into bochs since I > > got this change. (Well, I'm not sure it was > > this change, but I didn't see anything else.) > > Are you booting with FreeLoader or Loadros (boot.bat)? > I just checked out a clean tree, built it and booted it using Loadros. Runs > fine! FreeLoader -- but since building FreeLoader requires different tools I haven't yet bothered to get to the point where I can build it so I'm still using the version that shipped with the 0.0.19 bochs images. > With the last patch I changed the format of the 'group order list' from > semi-colon separated value string (REG_SZ) to multi string (REG_SZ_MULTI). > LoadRos doesn't handle this properly yet. I'll fix it tomorrow as soon as > I'm out of bed and had my first coffee. ;-) Given this, I'm guessing my problem is that I need a new version of freeldr. I guess I'll have to bite the bullet and get setup to build it. Thanks for the help, Joseph |
|
From: Eric K. <ek...@rz...> - 2002-06-10 09:01:27
|
ntoskrnl/io/drvlck.c (removed!)
ntoskrnl/mm/drvlck.c (new!)
ntoskrnl/makefile
Moved driver locking functions.
ntoskrnl/include/internal/io.h
ntoskrnl/include/internal/ldr.h
ntoskrnl/io/device.c
ntoskrnl/io/driver.c (new!)
ntoskrnl/io/iomgr.c
ntoskrnl/ke/main.c
ntoskrnl/ldr/loader.c
ntoskrnl/makefile
Minimize access to the module object via the object manager.
Use module list for internal module management.
Protect module list with a spinlock.
This is the first step of an attempt to reorganize and clean up the current
driver/module chaos. I removed all unneccessary accesses of module objects
via the object manager and replaced them by direct accesses via the module
list.
The next step of the cleanup will replace the current driver objects which
are currently represented by MODULE_OBJECTs by the real DRIVER_OBJECTs.
MODULE_OBJECTs will only be used as entries of the module list and won't
appear in the object manager namespace any more.
Regards,
Eric
|
|
From: Hartmut B. <har...@te...> - 2002-06-10 21:45:48
|
ntoskrnl\cc\copy.c: ntoskrnl\cc\view.c: ntoskrnl\include\internal\cc.h: ntoskrnl\ntoskrnl.def: ntoskrnl\ntoskrnl.edf: Implemented CcZeroData. ntoskrnl\cc\misc.c: Fixed a minor bug in CcSetFileSizes. drivers\fs\vfat\cleanup.c: drivers\fs\vfat\close.c: drivers\fs\vfat\vfat.h: Added updating of directory entries in VfatCleanupFile/VfatCloseFile. drivers\fs\vfat\rw.c: Updating the directory entries in VfatWrite only, if the allocation size has changed. Added zeroing for files, if the write starts after the current end of the file. drivers\fs\vfat\dirwr.c: Fixed a minor bug in updEntry. lib\msvcrt\stdio\fflush.c: Fixed fflush for non dirty file streams. lib\msvcrt\stdio\ftell.c: Fixed ftell for streams which are opened for reading and writing. lib\msvcrt\stdio\fread.c: lib\msvcrt\stdio\fwrite.c: Rewrote fread/fwrite for a better/faster handling of read/write requests. lib\msvcrt\sys_stat\fstat.c: Added flushing of file streams. ntoskrnl\ke\kthread.c: ntoskrnl\mm\cont.c: ntoskrnl\mm\balance.c: ntoskrnl\mm\i386\page.c: ntoskrnl\mm\ncache.c: ntoskrnl\mm\section.c: ntoskrnl\mm\virtual.c: Replaced all calls to MmDereferencePage with MmReleasePageMemoryConsumer. Added handling for multiple referenced pages in MmReleasePageMemoryConsumer. ntoskrnl\mm\mdl.c: Unmap the pages first and than remove the entries from the allocation map in MmUnmapLockedPages. ntoskrnl\ps\kill.c: Reference/Dereference the process object in PiTerminateProcess. - Hartmut |
|
From: Eric K. <ek...@rz...> - 2002-06-10 23:04:26
|
ntoskrnl/include/internal/io.h ntoskrnl/io/device.c ntoskrnl/io/driver.c ntoskrnl/io/pnpmgr.c ntoskrnl/ldr/loader.c Changed data structure which represents driver objects from MODULE_OBJECT to DRIVER_OBJECT. Now a DriverEntry's RegistryPath string is usable automagically. Eric |
×
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