Hello, I recently spent some time experimenting with various Cc rewrites we have in our tree, and before that I extensively tested our fastfat driver in a real NT environment (MS Windows 2003).
The conclusion of the above work is that our fastfat driver either needs serious bugfixing, or a rewrite is needed. It corrupts directory tables in a real NT, leads to unusual behaviour of cc- rewrite branch, and may have side effects on arty's newcc.
Before this is done (bugfixing or rewriting, developing and testing against a Windows 2003 at least, not ReactOS), it's meaningless to continue any other work on Cc and related Mm parts.
WBR, Aleksey Bragin.
On Wed, Jan 7, 2009 at 9:18 AM, Aleksey Bragin aleksey@reactos.org wrote:
Hello,I recently spent some time experimenting with various Cc rewrites we have in our tree, and before that I extensively tested our fastfat driver in a real NT environment (MS Windows 2003).
The conclusion of the above work is that our fastfat driver either needs serious bugfixing, or a rewrite is needed. It corrupts directory tables in a real NT, leads to unusual behaviour of cc- rewrite branch, and may have side effects on arty's newcc.
Before this is done (bugfixing or rewriting, developing and testing against a Windows 2003 at least, not ReactOS), it's meaningless to continue any other work on Cc and related Mm parts.
WBR, Aleksey Bragin. _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Let's make a plan! I want a proper branch for the cc rewrites. I'd like to have a live branch, not this half branch, half patch form that cc_rewrite is in now. Perhaps this would be a good place for the working fastfat to be dropped when finished.
I have time and resources that I could put towards this goal. Let's get fastfat working on 2k3, then drop it into a new cc branch and get it working..
<Leroy Jenkins>LET'S DO THIS, CHUMS!</Leroy Jenkins>
WD
On Jan 7, 2009, at 7:24 PM, WaxDragon wrote:
On Wed, Jan 7, 2009 at 9:18 AM, Aleksey Bragin aleksey@reactos.org wrote:
Hello,I recently spent some time experimenting with various Cc rewrites we have in our tree, and before that I extensively tested our fastfat driver in a real NT environment (MS Windows 2003).
The conclusion of the above work is that our fastfat driver either needs serious bugfixing, or a rewrite is needed. It corrupts directory tables in a real NT, leads to unusual behaviour of cc- rewrite branch, and may have side effects on arty's newcc.
Before this is done (bugfixing or rewriting, developing and testing against a Windows 2003 at least, not ReactOS), it's meaningless to continue any other work on Cc and related Mm parts.
WBR, Aleksey Bragin.
Let's make a plan! I want a proper branch for the cc rewrites. I'd like to have a live branch, not this half branch, half patch form that cc_rewrite is in now. Perhaps this would be a good place for the working fastfat to be dropped when finished.
I have time and resources that I could put towards this goal. Let's get fastfat working on 2k3, then drop it into a new cc branch and get it working..
<Leroy Jenkins>LET'S DO THIS, CHUMS!</Leroy Jenkins>
WD
Live branch needs constant merging. Have a look at amd64 bringup branch: most of commits are merges. That mm.patch is an ugly way of keeping the branch always uptodate...
Anyway, I have made some fixes to the branch, so if someone wants to test, I would need to commit my changes.
As for the fastfat, I think the problems is in synchronization somewhere, not in a pool corruption, passing invalid parameters, misusing Cc API, or anything like that - I fixed that already.
Another idea was to take ext2fsd by Matt Wu, which is supposed to work, and convert it to a fat32/16/12 driver.
The WDK ships with a working windows 2003 fat driver... rewrite it based on that one. Best regards, Alex Ionescu
On Wed, Jan 7, 2009 at 12:04 PM, Aleksey Bragin aleksey@reactos.org wrote:
On Jan 7, 2009, at 7:24 PM, WaxDragon wrote:
On Wed, Jan 7, 2009 at 9:18 AM, Aleksey Bragin aleksey@reactos.org wrote:
Hello,I recently spent some time experimenting with various Cc rewrites we have in our tree, and before that I extensively tested our fastfat driver in a real NT environment (MS Windows 2003).
The conclusion of the above work is that our fastfat driver either needs serious bugfixing, or a rewrite is needed. It corrupts directory tables in a real NT, leads to unusual behaviour of cc- rewrite branch, and may have side effects on arty's newcc.
Before this is done (bugfixing or rewriting, developing and testing against a Windows 2003 at least, not ReactOS), it's meaningless to continue any other work on Cc and related Mm parts.
WBR, Aleksey Bragin.
Let's make a plan! I want a proper branch for the cc rewrites. I'd like to have a live branch, not this half branch, half patch form that cc_rewrite is in now. Perhaps this would be a good place for the working fastfat to be dropped when finished.
I have time and resources that I could put towards this goal. Let's get fastfat working on 2k3, then drop it into a new cc branch and get it working..
<Leroy Jenkins>LET'S DO THIS, CHUMS!</Leroy Jenkins>
WD
Live branch needs constant merging. Have a look at amd64 bringup branch: most of commits are merges. That mm.patch is an ugly way of keeping the branch always uptodate...
Anyway, I have made some fixes to the branch, so if someone wants to test, I would need to commit my changes.
As for the fastfat, I think the problems is in synchronization somewhere, not in a pool corruption, passing invalid parameters, misusing Cc API, or anything like that - I fixed that already.
Another idea was to take ext2fsd by Matt Wu, which is supposed to work, and convert it to a fat32/16/12 driver.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi, how far can we use it? It must be under Microsoft copyright. Moreover, it must be quite complete, so it would not be a rewrite, just an importation. P. Schweitzer
Date: Wed, 7 Jan 2009 13:50:39 -0500 From: ionucu@videotron.ca To: ros-dev@reactos.org Subject: Re: [ros-dev] Cache / Memory Manager / FileSystemDrivers
The WDK ships with a working windows 2003 fat driver... rewrite it based on that one.Best regards, Alex Ionescu
On Wed, Jan 7, 2009 at 12:04 PM, Aleksey Bragin aleksey@reactos.org wrote:
On Jan 7, 2009, at 7:24 PM, WaxDragon wrote:
On Wed, Jan 7, 2009 at 9:18 AM, Aleksey Bragin
aleksey@reactos.org wrote:
Hello,
I recently spent some time experimenting with various Cc rewrites we
have in our tree, and before that I extensively tested our fastfat
driver in a real NT environment (MS Windows 2003).
The conclusion of the above work is that our fastfat driver either
needs serious bugfixing, or a rewrite is needed. It corrupts
directory tables in a real NT, leads to unusual behaviour of cc-
rewrite branch, and may have side effects on arty's newcc.
Before this is done (bugfixing or rewriting, developing and testing
against a Windows 2003 at least, not ReactOS), it's meaningless to
continue any other work on Cc and related Mm parts.
WBR,
Aleksey Bragin.
Let's make a plan! I want a proper branch for the cc rewrites. I'd
like to have a live branch, not this half branch, half patch form that
cc_rewrite is in now. Perhaps this would be a good place for the
working fastfat to be dropped when finished.
I have time and resources that I could put towards this goal. Let's
get fastfat working on 2k3, then drop it into a new cc branch and get
it working..
<Leroy Jenkins>LET'S DO THIS, CHUMS!</Leroy Jenkins>
WD
Live branch needs constant merging. Have a look at amd64 bringup
branch: most of commits are merges. That mm.patch is an ugly way of
keeping the branch always uptodate...
Anyway, I have made some fixes to the branch, so if someone wants to
test, I would need to commit my changes.
As for the fastfat, I think the problems is in synchronization
somewhere, not in a pool corruption, passing invalid parameters,
misusing Cc API, or anything like that - I fixed that already.
Another idea was to take ext2fsd by Matt Wu, which is supposed to
work, and convert it to a fat32/16/12 driver.
_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
_________________________________________________________________ Téléphonez gratuitement à tous vos proches avec Windows Live Messenger ! Téléchargez-le maintenant ! http://www.windowslive.fr/messenger/1.asp
You need to rewrite it to fulfill all the licensing requirements. Many things in FASTFAT aren't needed for us yet, so in theory (IANAL), even stripping out those parts and keeping the rest of the driver intact would be ok -- based on my knowledge that copyright law states that you need to copy
70% for it to be considered "the same work", anything less than that and
it's okay (again, IANAL).
So my opinion (IANAL!!!) is that if you use the WDK FASTFAT driver as a reference source, and write (on your own, not copy pasting) the same interfaces/function names/data types/structures (which are, by definition, not copyrightable), and then write your own code (use a different layout, optimize the functions, use other variables/similar code logic, etc) and additionally, only implement, for now, say half the driver, you'd be 100% legal, at least in the US and other countries that signed the WIPO I think it's called.
Best regards, Alex Ionescu
2009/1/7 Pierre SCHWEITZER heis_spiter@hotmail.com
Hi, how far can we use it? It must be under Microsoft copyright. Moreover, it must be quite complete, so it would not be a rewrite, just an importation. P. Schweitzer
Date: Wed, 7 Jan 2009 13:50:39 -0500 From: ionucu@videotron.ca To: ros-dev@reactos.org Subject: Re: [ros-dev] Cache / Memory Manager / FileSystemDrivers
The WDK ships with a working windows 2003 fat driver... rewrite it based on that one. Best regards, Alex Ionescu
On Wed, Jan 7, 2009 at 12:04 PM, Aleksey Bragin aleksey@reactos.orgwrote:
On Jan 7, 2009, at 7:24 PM, WaxDragon wrote:
On Wed, Jan 7, 2009 at 9:18 AM, Aleksey Bragin aleksey@reactos.org wrote:
Hello,I recently spent some time experimenting with various Cc rewrites we have in our tree, and before that I extensively tested our fastfat driver in a real NT environment (MS Windows 2003).
The conclusion of the above work is that our fastfat driver either needs serious bugfixing, or a rewrite is needed. It corrupts directory tables in a real NT, leads to unusual behaviour of cc- rewrite branch, and may have side effects on arty's newcc.
Before this is done (bugfixing or rewriting, developing and testing against a Windows 2003 at least, not ReactOS), it's meaningless to continue any other work on Cc and related Mm parts.
WBR, Aleksey Bragin.
Let's make a plan! I want a proper branch for the cc rewrites. I'd like to have a live branch, not this half branch, half patch form that cc_rewrite is in now. Perhaps this would be a good place for the working fastfat to be dropped when finished.
I have time and resources that I could put towards this goal. Let's get fastfat working on 2k3, then drop it into a new cc branch and get it working..
<Leroy Jenkins>LET'S DO THIS, CHUMS!</Leroy Jenkins>
WD
Live branch needs constant merging. Have a look at amd64 bringup branch: most of commits are merges. That mm.patch is an ugly way of keeping the branch always uptodate...
Anyway, I have made some fixes to the branch, so if someone wants to test, I would need to commit my changes.
As for the fastfat, I think the problems is in synchronization somewhere, not in a pool corruption, passing invalid parameters, misusing Cc API, or anything like that - I fixed that already.
Another idea was to take ext2fsd by Matt Wu, which is supposed to work, and convert it to a fat32/16/12 driver.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Discutez sur Messenger où que vous soyez ! Mettez Messenger sur votre mobile ! http://www.messengersurvotremobile.com/
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
It might be possible to reuse parts of existing vfat driver routines (which there is no doubt about correctness).
Anyone objects to such approach (a real *rewrite* of a driver, not just porting WDK's fastfat sample)? If noone, I consider this a way to go.
WBR, Aleksey.
On Jan 7, 2009, at 11:13 PM, Alex Ionescu wrote:
You need to rewrite it to fulfill all the licensing requirements.
Many things in FASTFAT aren't needed for us yet, so in theory (IANAL), even stripping out those parts and keeping the rest of the driver intact would be ok -- based on my knowledge that copyright law states that you need to copy > 70% for it to be considered "the same work", anything less than that and it's okay (again, IANAL).
So my opinion (IANAL!!!) is that if you use the WDK FASTFAT driver as a reference source, and write (on your own, not copy pasting) the same interfaces/function names/data types/structures (which are, by definition, not copyrightable), and then write your own code (use a different layout, optimize the functions, use other variables/similar code logic, etc) and additionally, only implement, for now, say half the driver, you'd be 100% legal, at least in the US and other countries that signed the WIPO I think it's called.
Best regards, Alex Ionescu
On Wed, 7 Jan 2009 20:04:34 +0300 Aleksey Bragin aleksey@reactos.org wrote:
On Jan 7, 2009, at 7:24 PM, WaxDragon wrote:
On Wed, Jan 7, 2009 at 9:18 AM, Aleksey Bragin aleksey@reactos.org wrote:
Hello,I recently spent some time experimenting with various Cc rewrites we have in our tree, and before that I extensively tested our fastfat driver in a real NT environment (MS Windows 2003).
The conclusion of the above work is that our fastfat driver either needs serious bugfixing, or a rewrite is needed. It corrupts directory tables in a real NT, leads to unusual behaviour of cc- rewrite branch, and may have side effects on arty's newcc.
Before this is done (bugfixing or rewriting, developing and testing against a Windows 2003 at least, not ReactOS), it's meaningless to continue any other work on Cc and related Mm parts.
WBR, Aleksey Bragin.
Let's make a plan! I want a proper branch for the cc rewrites. I'd like to have a live branch, not this half branch, half patch form that cc_rewrite is in now. Perhaps this would be a good place for the working fastfat to be dropped when finished.
I have time and resources that I could put towards this goal. Let's get fastfat working on 2k3, then drop it into a new cc branch and get it working..
<Leroy Jenkins>LET'S DO THIS, CHUMS!</Leroy Jenkins>
WD
Live branch needs constant merging. Have a look at amd64 bringup branch: most of commits are merges. That mm.patch is an ugly way of keeping the branch always uptodate...
Anyway, I have made some fixes to the branch, so if someone wants to test, I would need to commit my changes.
As for the fastfat, I think the problems is in synchronization somewhere, not in a pool corruption, passing invalid parameters, misusing Cc API, or anything like that - I fixed that already.
Another idea was to take ext2fsd by Matt Wu, which is supposed to work, and convert it to a fat32/16/12 driver.
I've been working on some things under git over svn. Merging trunk has been pretty easy this way, although some assembly was required. Perhaps rather than switching, we can start a git repository just for branches and feed it from svn, also using it to build diffs for merging back to trunk.
Aleksey Bragin wrote:
Live branch needs constant merging. Have a look at amd64 bringup branch: most of commits are merges. That mm.patch is an ugly way of keeping the branch always uptodate...
This is the reason all my branches are now local (and my lack of commits, making it look like I do nothing anymore) It was a great idea until my laptop was stolen and I lost all my code ....
Strange that this just popped up as Timo and I were only talking about this the other day :
<Physicus> atm I'm fine with SVN for reactos. What i would wish to have was some kind of "virtual branch" or "intermediate branch" something between trunk and your local copy where you can commit to and that does receive commits from trunk. So it stays in sync with trunk. <Physicus> Both a remote and a local solution would be great <GedMurphy> that's the exact reason I don't use branches <Physicus> the sync mess <GedMurphy> yeah, too much hard work and lost time <GedMurphy> I have about 5 local branches instead <GedMurphy> it worked fine, until my laptop was stolen and I lost all my code ... lol <GedMurphy> although, I've recreated most of my old branches over the Christmas period, so I obviously don't learn ;) <Physicus> That's what my idea is about. You create an intermediate branch (either locally or on a remote server) then checkout a local copy. Your commits go to that intermediate branch, but commits to trunk do also go there. If there's a conflict, you need to resolve it as normally when working directly with trunk <GedMurphy> that would be perfect <Physicus> Make svn people implement something like that and we might get people working on branches
One word: Mercurial. Steven, pitch in and back me up.
Best regards, Alex Ionescu
On Thu, Jan 8, 2009 at 5:48 AM, Ged gedmurphy@gmail.com wrote:
Aleksey Bragin wrote:
Live branch needs constant merging. Have a look at amd64 bringup branch: most of commits are merges. That mm.patch is an ugly way of keeping the branch always uptodate...
This is the reason all my branches are now local (and my lack of commits, making it look like I do nothing anymore) It was a great idea until my laptop was stolen and I lost all my code ....
Strange that this just popped up as Timo and I were only talking about this the other day :
<Physicus> atm I'm fine with SVN for reactos. What i would wish to have was some kind of "virtual branch" or "intermediate branch" something between trunk and your local copy where you can commit to and that does receive commits from trunk. So it stays in sync with trunk. <Physicus> Both a remote and a local solution would be great <GedMurphy> that's the exact reason I don't use branches <Physicus> the sync mess <GedMurphy> yeah, too much hard work and lost time <GedMurphy> I have about 5 local branches instead <GedMurphy> it worked fine, until my laptop was stolen and I lost all my code ... lol <GedMurphy> although, I've recreated most of my old branches over the Christmas period, so I obviously don't learn ;) <Physicus> That's what my idea is about. You create an intermediate branch (either locally or on a remote server) then checkout a local copy. Your commits go to that intermediate branch, but commits to trunk do also go there. If there's a conflict, you need to resolve it as normally when working directly with trunk <GedMurphy> that would be perfect <Physicus> Make svn people implement something like that and we might get people working on branches
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
One word: Buggy
Both Aleksey and me already tried to convert our SVN repository to Hg, but it failed all the time. Aleksey even tried it recently again before starting this GIT mirror. More information at http://www.selenic.com/mercurial/bts/issue1197
Best regards,
Colin
_____
From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Alex Ionescu Sent: Thursday, January 08, 2009 8:35 PM To: ReactOS Development List Subject: Re: [ros-dev] Cache / Memory Manager / FileSystemDrivers
One word: Mercurial.
Steven, pitch in and back me up.
Best regards, Alex Ionescu
On Thu, Jan 8, 2009 at 5:48 AM, Ged gedmurphy@gmail.com wrote:
Aleksey Bragin wrote:
Live branch needs constant merging. Have a look at amd64 bringup branch: most of commits are merges. That mm.patch is an ugly way of keeping the branch always uptodate...
This is the reason all my branches are now local (and my lack of commits, making it look like I do nothing anymore) It was a great idea until my laptop was stolen and I lost all my code ....
Strange that this just popped up as Timo and I were only talking about this the other day :
<Physicus> atm I'm fine with SVN for reactos. What i would wish to have was some kind of "virtual branch" or "intermediate branch" something between trunk and your local copy where you can commit to and that does receive commits from trunk. So it stays in sync with trunk. <Physicus> Both a remote and a local solution would be great <GedMurphy> that's the exact reason I don't use branches <Physicus> the sync mess <GedMurphy> yeah, too much hard work and lost time <GedMurphy> I have about 5 local branches instead <GedMurphy> it worked fine, until my laptop was stolen and I lost all my code ... lol <GedMurphy> although, I've recreated most of my old branches over the Christmas period, so I obviously don't learn ;) <Physicus> That's what my idea is about. You create an intermediate branch (either locally or on a remote server) then checkout a local copy. Your commits go to that intermediate branch, but commits to trunk do also go there. If there's a conflict, you need to resolve it as normally when working directly with trunk <GedMurphy> that would be perfect <Physicus> Make svn people implement something like that and we might get people working on branches
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I actually had a conversion going but a power outage took it out. It was however going steadly without problems.
Advantages of Mercurial? Better Windows support would be a big one. And just because Wine and other projects use Git does not mean it is automatically suited to this project.
On Thu, Jan 8, 2009 at 2:15 PM, Alexander Potashev aspotashev@gmail.comwrote:
On 14:35 Thu 08 Jan , Alex Ionescu wrote:
One word: Mercurial. Steven, pitch in and back me up.
But what are the advantages of Mercurial for ReactOS? Wine and many other projects uses Git...
Best regards, Alex Ionescu
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
GIT is pretty much unusable for us Windows users. It's ugly and clunky and goes hand in hand with linux.
HG is much better alternative, if nothing else other than the tortoise shell extension we're all so accustomed to with TSVN.
It's a shame it's problematic to move to at the moment.
From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Zachary Gorden Sent: 08 January 2009 20:42 To: ReactOS Development List Subject: Re: [ros-dev] Cache / Memory Manager / FileSystemDrivers
I actually had a conversion going but a power outage took it out. It was however going steadly without problems.
Advantages of Mercurial? Better Windows support would be a big one. And just because Wine and other projects use Git does not mean it is automatically suited to this project.
On Thu, Jan 8, 2009 at 2:15 PM, Alexander Potashev aspotashev@gmail.com wrote:
On 14:35 Thu 08 Jan , Alex Ionescu wrote:
One word: Mercurial. Steven, pitch in and back me up.
But what are the advantages of Mercurial for ReactOS? Wine and many other projects uses Git...
Best regards, Alex Ionescu
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
I thought the same before I tried msysgit + TortoiseGit. As for the first, core package, msysgit is a native port, and I must say, it indeed works well. As for the second, TortoiseGit, it's an in- development tool based on TortoiseSVN and is already usable. Yes, it lacks many things, "Not yet implemented" messageboxes are quite often, but, basic needed operations are there, diff/merger are there, and it doesn't look like an abandoned project.
At least, I don't really want to bugfix Mercurial itself if I have a working solution with Git under Windows. And many of you know I'm no fan of cmd line tools :-)
WBR, Aleksey.
On Jan 9, 2009, at 12:21 AM, Ged wrote:
GIT is pretty much unusable for us Windows users. It’s ugly and clunky and goes hand in hand with linux.
HG is much better alternative, if nothing else other than the tortoise shell extension we’re all so accustomed to with TSVN.
It’s a shame it’s problematic to move to at the moment.
-
Aleksey Bragin -
Alex Ionescu -
Alexander Potashev -
art yerkes -
Colin Finck -
Ged -
Pierre SCHWEITZER -
WaxDragon -
Zachary Gorden