Hi,
Anyone have any Comments, Flames or Suggestions before I send this ?
Tom
"Tom Wickline" twickline@skybest.com wrote:
Anyone have any Comments, Flames or Suggestions before I send this ?
Looks good, except the kernel32 API description URL (Kernel-Mode Driver Architecture). Kernel32 has a lot of function groups, but none of them has any relationship to kernel mode drivers.
One more point: I just have found that status page completely misses GDI32 status.
Yeah, looks good to me. A few things:
* Robert Reif has done some DSound work lately.
* Might want to add "DirectX Transforms", which is a set of image manipulation objects used by a few apps (internet explorer). 0% completed. Not critical though, nothing that I know of actually requires them.
* cabinet.dll is much higher than 35% now, esp with Gregs latest patches. I can't really say how much, but perhaps more like 80%? Greg would have to say......
On Monday 16 June 2003 08:54 am, Mike Hearn wrote:
- cabinet.dll is much higher than 35% now, esp with Gregs latest
patches. I can't really say how much, but perhaps more like 80%? Greg would have to say......
No way, I beg to differ. Remember there's a whole encoding API that hasn't even been started yet. Once I finish split cab's I'll recommend 60% or something, but not before -- a plurality of in-the-wild cabs are split, so the code I have submitted up 'til now is severely crippled until I do this final step.
Do we measure percent implemented or percent useful? If the latter, maybe it's a different story. But encoding is inherently harder to implement than decoding (there's a lot more "to do", and usually no single right answer, so you never know when you're done). I own a nice book on compression, and I could do this code, but also I would be implementing from scratch instead of borrowing from others... so if these percents measure man-hours, we very well might be at more like 15%!
Even if we say FDI and FCI are equal, then I guess FDI comprises 40%, FCI comprises 40%, and the undocumented parts comprise 20%. That would mean we will have 60% implemented, exactly the same as my guesstimate, pending completion of the FDI implementation.
Besides, I'm not sure if CVS has caught up with me yet. Haven't checked for a little while, since I've been too busy tinkering to worry about merging...
Whatever, it's just a number, but I have to respectfully disagree with 80%; Tom & I have had private communications about this, and he is up-to-speed.
Gregory M. Turner wrote:
But encoding is inherently harder to implement than decoding (there's a lot more "to do", and usually no single right answer, so you never know when you're done).
Ah?
Every book, software and piece of common knowledge tells me that decoding is WAY more difficult. "Be restrictive in what you produce, and permissive in what you accept" means that, when decoding, you need to accept broken encodings too, as well as encodings that took a different path than the one you would take (different algorithm, different paramters, optional parameters, etc). When encoding, you need to select a single path and go that way.
I own a nice book on compression, and I could do this code, but also I would be implementing from scratch instead of borrowing from others... so if these percents measure man-hours, we very well might be at more like 15%!
I think there is no definite answer, but the general gist is that we measure usability.
Shachar
On Tuesday 17 June 2003 12:43 am, Shachar Shemesh wrote:
Gregory M. Turner wrote:
But encoding is inherently harder to implement than decoding (there's a lot more "to do", and usually no single right answer, so you never know when you're done).
Ah?
Every book, software and piece of common knowledge tells me that decoding is WAY more difficult. "Be restrictive in what you produce, and permissive in what you accept" means that, when decoding, you need to accept broken encodings too, as well as encodings that took a different path than the one you would take (different algorithm, different paramters, optional parameters, etc). When encoding, you need to select a single path and go that way.
Hmm, that's a good point, I never thought of it that way. I guess I was thinking in terms of computational complexity, but from a difficulty-of-implementation perspective (which is what I was intending to address), I think you are right, I have it backwards above. In this particular case, however, the fact that the decompression code was gifted to us probably nevertheless reverses the relative labor requirements we would expect based on that principle.
On Tuesday 17 June 2003 12:43 am, Shachar Shemesh wrote:
I think there is no definite answer, but the general gist is that we measure usability.
If usability is, indeed, what I'm supposed to be measuring, that could change my opinion. It's not clear to me whether anything really uses the FCI (compression) APIs in cabinet.dll... so far, I have yet to hear of anyone's app bombing out due to an unimplemented FCI API.
So, maybe the percentage should, indeed, go higher, to 80% or what-have-you (I'd still like to finish split cabs, and build some tests, before we go bumping the completion percentage). Visual Studio seems to statically link against cabinet.dll anyhow -- it's quite possible it wouldn't come up much at all -- maybe in WinZip or something. Certainly the most urgent need for this implementation is to get various installers working, which AFAIK only requires decompression.
Btw, there are some setupapi APIs which ought to be trivial to bang out once the FDI APIs are in place... I think they are all decompression-only, which would tend to strengthen the argument that the majority of the utility of the dll is in the decompression APIs.
Gregory M. Turner wrote:
So, maybe the percentage should, indeed, go higher, to 80% or what-have-you (I'd still like to finish split cabs, and build some tests, before we go bumping the completion percentage).
It won't reach 100% until it's ready. That aside - this is an OpenSource project. You decide what your itch is.
Visual Studio seems to statically link against cabinet.dll anyhow -- it's quite possible it wouldn't come up much at all -- maybe in WinZip or something.
I doubt winzip is using any of MS's compression, but I may be wrong here. Check your assumptions against real life is my advice.
Certainly the most urgent need for this implementation is to get various installers working, which AFAIK only requires decompression.
Btw, there are some setupapi APIs which ought to be trivial to bang out once the FDI APIs are in place... I think they are all decompression-only, which would tend to strengthen the argument that the majority of the utility of the dll is in the decompression APIs.
It appears that where work/result is concerned, decompression is the most important part.
On Tuesday 17 June 2003 01:52 am, Shachar Shemesh wrote:
Gregory M. Turner wrote:
Visual Studio seems to statically link against cabinet.dll anyhow -- it's quite possible it wouldn't come up much at all -- maybe in WinZip or something.
I doubt winzip is using any of MS's compression, but I may be wrong here. Check your assumptions against real life is my advice.
They use the FDI API's from cabinet.dll to do cab decompression, or so I have read. I don't know if they support cab creation the same way, or at all. As you mention, there is one way to find out for sure.
Hello,
Changes since lat post.....
Change Kernel Doc url to : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winprog/win...
Add : GDI32 worker: Codeweavers, Aric Stwart, Huw D.M Davis, Alexandre Julliard Status: 60%
P.S
Should I add in hal, icm, ctl3d, and other dll's that I dont have listed now or wait untill the next update ?
if not i think ive got the dll's status about done..... if anyone thinks i should add in the extra dll's ill have it ready in a day or so.... I just need to know what you guy's think about the missing _system_ dll's........ wait or now ????????
Tom
-
Dmitry Timoshkov -
Gregory M. Turner -
Mike Hearn -
Shachar Shemesh -
Tom -
Tom Wickline