Looking at the ks.sys file properties, I see that it says:
File description: Kernel CSA Library
What does CSA mean? What do the initials refer to?
Perhaps Tim Roberts will know 
Paul_Jackson wrote:
> File description: Kernel CSA Library
What does CSA mean? What do the initials refer to?
“Connection and Streaming Architecture”. This was the original name for
collection of technologies we now think of as “kernel streaming”: port
class, stream class, and AVStream. You can still find a few internet
references to WDM-CSA. The design work was done in concert with
DirectShow (which, I’m sure we all know, used to be called ActiveMovie,
and Quartz before that).
And when I say “very old”, the design work for KS (CSA) was all done for
Windows 98 and Windows NT 4.0. It is a testament to the forward
thinking of these designers that AVStream drivers written and compiled
for Windows 98 still work perfectly well today.
Thanks Tim.
Another, related question: do you happen to know what does “ax” in file names such as ksproxy.ax stand for?
On Apr 6, 2019, at 2:30 PM, Paul_Jackson wrote:
>
> Another, related question: do you happen to know what does “ax” in file names such as ksproxy.ax stand for?
ActiveX. COM servers were originally called ActiveX controls.
You can see that Microsoft goes through phases where everything gets a marketing scent. For a while, everything was Active: ActiveX, ActiveMovie, etc. Then everything was Direct: DirectX, DirectDraw, DirectShow, DirectInput. For a while, everything was Visual.
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
You can see that Microsoft goes through phases where everything gets a marketing scent. For a while, everything was Active:
ActiveX, ActiveMovie, etc. Then everything was Direct: DirectX, DirectDraw, DirectShow, DirectInput.
For a while, everything was Visual.
This is not entirely correct, at least as far as DirectX is concerned…
The very term"direct" relates to a direct communication channel between the API in question and underlying device drivers.
It was designed for the needs of game/multimedia developers, and allowed them to work around the limitations of “conventional” API designed for the “regular” apps. For example, DirectDraw and Direct3D allowed game developers to speak to display drivers directly, without the overhead that GDI/USER API impose. In fact, you can think of them as of Windows-specific equivalent of OpenGL. DirectSound takes the same approach to audio - it exposes interfaces that allow bypassing the “conventional” audio API.
DirectDraw, Direct3D, DirectSound and DirectPlay were designed for lower-level developers, and, hence, exposed C/C+±based API. DirectShow was designed for higher-level programmers who prefered the managed languages (or even the scripting ones).
OTOH, DirectMusic seems to be, indeed, more of a marketing term, rather than a technology - it is just a set of objects built on top of DirectSound
ActiveX. COM servers were originally called ActiveX controls.
…and ActiveX was just a subset of COM technology, which was a MSFT equivalent of CORBA…
So-called ActiveX controls (IIRC, their file extension was .ocx) were, in actuality, DLLs that were required to expose a certain subset of
pre-defined COM interfaces that allowed them to communicate with the client apps they were loaded into. However, COM was more than that.
Besides above mentioned ActiveX controls (known as “in-process servers” in COM lingo), it also allowed “out-of -process” ones. These were
the applications in their own right that could expose their functionality to other apps as COM interfaces. Once every process has its own address space, all calls to these servers from the client processes has to be marchalled.
The whole concept of marchalling parameters is closely related to RPC. One had to specify these interfaces in so-called “Microsoft Interface Description Language” (which was just a subset of IDL designed by Sun Microsystems, with some non-standard extensions added), and input them to MIDL compiler, which produced a C code that actually dealt with passing the parameters across the process boundaries.
The beauty of this approach is that one can take an in-proc server to another machine, as well as substitute the server A with
the server B that exposes the same interface, transparently to its clients
Anton Bassov
—
On Apr 7, 2019, at 3:50 AM, anton_bassov wrote:
>
> This is not entirely correct, at least as far as DirectX is concerned…
>
> The very term “direct” relates to a direct communication channel between the API in question and underlying device drivers.
I’m surprised to find that you have swallowed the Microsoft marketing kool-aid on this point. The “Direct” umbrella term was no more technology-driven than the “Active” umbrella term or the “.NET” umbrella term. They are all just branding. Direct3D iand DirectSound are no more “direct to the API” than GDI. It’s just a richer API.
> DirectDraw, Direct3D, DirectSound and DirectPlay were designed for lower-level developers, and, hence, exposed C/C+±based API. DirectShow was designed for higher-level programmers who prefered the managed languages (or even the scripting ones).
No. DirectShow (nee ActiveMovie) was introduced LONG before managed languages were even a bullet point in a developer’s PowerPoint deck. The first release was in May of 1996. The fact that it is STILL the best multimedia framework available for Windows (or Linux, for that matter) is quite a testament.
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
I’m surprised to find that you have swallowed the Microsoft marketing kool-aid on this point. The “Direct” umbrella term
was no more technology-driven than the “Active” umbrella term or the “.NET” umbrella term. They are all just branding.
Direct3D iand DirectSound are no more “direct to the API” than GDI. It’s just a richer API.
Please note that DirectX originated under Window9x. I had a first-hand experience with DirectDraw and Direct3D under Windows 95. Therefore, I can attest that the API was, indeed, “rich” - it allowed you to literally freeze the system, and render it unusable without a slightest effort. Certainly, Windows 95 may have had a reputation for everything but its “legendary stability”, but hanging the system with DirectDraw and Direct3D was a way too easy even by Win9x standards. Therefore, I suspect that the term “direct” might have been more than just a marketing ploy, at least as far as Windows9x world was concerned…
I would not be too sure about the NT one, because I have never programmed DirectX under NT. On one hand, we may assert that the term "direct"must very obviously be a misnomer - you cannot directly deal with drivers from the userland, can you. This is defined by the system architecture, and applies to any more or less serious OS.
OTOH, I can present an example that defies the above assertion. It is our good old SoftIce debugger. You cannot call the GDI (as well as upon any other system service) functions on a debugee while running a kernel debug session on uniprocessor system, can you.
Therefore, in order to allow kernel-level debugging on the same machine, SoftIce, AFAIK, utilised DirectDraw. The screen that popped up when you hit Ctrl +D keys was, AFAIK, implemented as a DirectDraw surface. AFAIK, SoftIce was assessing this surface from the kernel by exactly the same means that system-provided DirectDraw implementation did behind the scenes when its methods were called from the userland.
To make it even more interesting, you had a pretty good chance to experience exactly the same GUI freeze that Win9x did when SoftIce window was active. This makes me suspect that that the term “direct” is, probably, a bit more than just a marketing ploy in the NT world as well…
No. DirectShow (nee ActiveMovie) was introduced LONG before managed languages were even a bullet point in a developer’s PowerPoint >deck. The first release was in May of 1996.
IIRC, ActiveMovie was implemented as an ActiveX control, i.e. a mechanism that is particularly suitable for the managed languages like VB.
You are not saying that VB did not exist back then, are you. It was designed to work with InternetExplorer, so that it could be utilised by the scripting languages like VB Script. The only thing that did not exist back then was the very term “a managed language”- IIRC, this term turned up only with the advent of .NET, which had arrived 5 years later
Anton Bassov