Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

qedit.dll missing under Windows 2008 RC0

1,492 views
Skip to first unread message

rk

unread,
Oct 31, 2007, 4:51:02 AM10/31/07
to
i'm missing the qedit.dll which contains the ISampleGrabber interface. Will
it be contained in the final release?

i tried to copy the dll from vista into

c:\windows\system32

and executed

regsvr32 c:\windows\system32\qedit.dll


ISamplegrabber is available under Windows2008, after running this reg file:

********************************
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\CLSID\{083863F1-70DE-11D0-BD40-00A0C911CE86}\Instance\{C1F400A0-3F08-11D3-9F0B-006008039E37}]
"FriendlyName"="SampleGrabber"
"FilterData"=hex:02,00,00,00,00,00,20,00,02,00,00,00,00,00,00,00,30,70,69,33,\
00,00,00,00,00,00,00,00,01,00,00,00,00,00,00,00,00,00,00,00,30,74,79,33,00,\
00,00,00,60,00,00,00,60,00,00,00,31,70,69,33,08,00,00,00,00,00,00,00,01,00,\
00,00,00,00,00,00,00,00,00,00,30,74,79,33,00,00,00,00,60,00,00,00,60,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
"CLSID"="{C1F400A0-3F08-11D3-9F0B-006008039E37}"

[HKEY_CLASSES_ROOT\CLSID\{C1F400A0-3F08-11D3-9F0B-006008039E37}]
@="Sample Grabber"

[HKEY_CLASSES_ROOT\CLSID\{C1F400A0-3F08-11D3-9F0B-006008039E37}\InprocServer32]
@="C:\\Windows\\System32\\qedit.dll"
"ThreadingModel"="Both"
***************************

This works for my test scenario, but this is not a solution for our
cusromers who want to run our application under Windows 2008

What is the correct solution to get access to ISampleGrabber in Windows 2008?

best regards

rk

The March Hare [MVP]

unread,
Oct 31, 2007, 2:36:25 PM10/31/07
to
On Wed, 31 Oct 2007 01:51:02 -0700, rk wrote:

> This works for my test scenario, but this is not a solution for our
> cusromers who want to run our application under Windows 2008
>
> What is the correct solution to get access to ISampleGrabber in Windows 2008?

My guess is that qedit.dll has been permanently removed from Windows Server
2008. This means that you cannot use its interfaces on this version of
Windows. As you noted, you cannot legally copy the DLL from another
version of Windows.

I will check with the dshow team tomorrow when I will be on a conference
call with some of them.

--
Please read this before replying:
1. Dshow & posting help: http://tmhare.mvps.org/help.htm
2. Trim & respond inline (please don't top post or snip everything)
3. Benefit others: follow up if you are helped or you found a solution

rk

unread,
Oct 31, 2007, 3:41:03 PM10/31/07
to
> My guess is that qedit.dll has been permanently removed from Windows Server
> 2008. This means that you cannot use its interfaces on this version of
> Windows. As you noted, you cannot legally copy the DLL from another
> version of Windows.

This would make our application for Windows 2008 unusable!

In this case our customers will not upgrade from Windows 2003 to Windows
2008 until we have found a solution, because about 90% of them use only our
application on their systems.

>
> I will check with the dshow team tomorrow when I will be on a conference
> call with some of them.

I am very hopeful ...

The March Hare [MVP]

unread,
Oct 31, 2007, 4:05:14 PM10/31/07
to
On Wed, 31 Oct 2007 12:41:03 -0700, rk wrote:

> This would make our application for Windows 2008 unusable!

I will pass this along tomorrow.



> In this case our customers will not upgrade from Windows 2003 to Windows
> 2008 until we have found a solution, because about 90% of them use only our
> application on their systems.

Out of interest, why are you using a server o/s for an application that
needs qedit.dll?

Chris P.

unread,
Oct 31, 2007, 5:52:19 PM10/31/07
to
On Wed, 31 Oct 2007 14:05:14 -0600, The March Hare [MVP] wrote:

> On Wed, 31 Oct 2007 12:41:03 -0700, rk wrote:
>
>> This would make our application for Windows 2008 unusable!
>
> I will pass this along tomorrow.
>
>> In this case our customers will not upgrade from Windows 2003 to Windows
>> 2008 until we have found a solution, because about 90% of them use only our
>> application on their systems.
>
> Out of interest, why are you using a server o/s for an application that
> needs qedit.dll?

Believe me it's not all that uncommon. It may be due to the particular
solution suite that uses a combination of software, e.g. SQL Server,
Sharepoint etc.

Or it may be due to the particular hardware you wish to run your solution
on. For example Dell 1U servers make a good solid low-profile platform for
video capture, but the only choice of operating system when purchasing in
Server 2003 or RedHat. No OS is also a choice, and we have been known to
by these servers and install OEM XP on them but it can be a PITA finding
drivers when Dell doesn't officially support this combination. And no it's
not just Dell that does this, it's all the manufacturers AFAIK.

--
http://www.chrisnet.net/code.htm
[MS MVP for DirectShow / MediaFoundation]

rk

unread,
Oct 31, 2007, 6:17:00 PM10/31/07
to
> Out of interest, why are you using a server o/s for an application that
> needs qedit.dll?

Our customers use it. Under XP, Vista and 2003 our application works fine .
The problem is that you have the choice between windows 2003 or linux, if you
buy a rack or blade server for example a dell system. There is no xp or vista
availabel on these kind of machines, but our customers prefer such machines.

A lot of them rent machines in a webfarm, which have windows 2003 web
edition installed.

A lot of our customer sells hardware together with our software to end
users. And these resellers (our customer) are prefering server systems,
because it seems, that the end users request a server system, without a
technical background (thanks to marketing ;-)

rk

Alessandro Angeli

unread,
Oct 31, 2007, 6:44:23 PM10/31/07
to
From: "rk"

> This would make our application for Windows 2008 unusable!
>
> In this case our customers will not upgrade from Windows
> 2003 to Windows 2008 until we have found a solution,
> because about 90% of them use only our application on
> their systems.

If all you need out of qedit.dll is the SampleGrabber
filter, why don't you just embed a custom sample grabber in
your own application so you don't need qedit.dll at all?
Depending on what features of the stock SampleGrabber you
are using, writing a custom one ranges from half a page of
code to a few pages. The old SDK (the one bundled with the
DirectX SDK 9.0b 2003/2004) even contains such a filter
among the samples.


--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm


The March Hare [MVP]

unread,
Oct 31, 2007, 8:39:18 PM10/31/07
to
On Wed, 31 Oct 2007 18:44:23 -0400, Alessandro Angeli wrote:

> If all you need out of qedit.dll is the SampleGrabber
> filter, why don't you just embed a custom sample grabber in
> your own application so you don't need qedit.dll at all?

Good point A.

rk

unread,
Nov 1, 2007, 6:40:00 AM11/1/07
to
"The March Hare [MVP]" wrote:

> On Wed, 31 Oct 2007 18:44:23 -0400, Alessandro Angeli wrote:
>
> > If all you need out of qedit.dll is the SampleGrabber
> > filter, why don't you just embed a custom sample grabber in
> > your own application so you don't need qedit.dll at all?

Alessandro thanks for this helpful hint, but i don't know if SampleGrabber
is the only filter i need from this dll. It was the first error that occured,
and after copying the Vista dll the app works. It is possible that another
error appears after developing a custom SampleGrabber ...

>
> Good point A.

Maybe, but for me it is an worst case scenario! The reasons are:

1. I'm not DirectX developer, i am developer that uses DirectX
2. The samplegrabber is embedded in 3rd party components
3. I've never used the DirectX SDK for developing, so it will take some time
to develop such a filter
4. I've to do a lot of work, just for get compatiblity for an "old app"
5. We have to do a lot of tests
6. We've different installtions for XP,Vista,2003 <-> 2008
7. This could break our xopy deployment, because i think we've to register
this custom samplegrabber in the registry.

I would be really disappointed, if qedit.dll not exists in the final release
of 2008.

rk


The March Hare [MVP]

unread,
Nov 1, 2007, 10:05:04 AM11/1/07
to
On Thu, 1 Nov 2007 03:40:00 -0700, rk wrote:

> I would be really disappointed, if qedit.dll not exists in the final release
> of 2008.

A question for me to investigate is whether the DX SDK was ever specified
for use with Windows Server (2003 in particular but earlier versions as
well). IIRC, there were issues before around Server support but I don't
remember if it was ever officially supported. I'll bring this up on the
call (Chris is interested in the issue as well and will likely be on the
call).

The March Hare [MVP]

unread,
Nov 1, 2007, 12:12:32 PM11/1/07
to
On Thu, 1 Nov 2007 03:40:00 -0700, rk wrote:

> I would be really disappointed, if qedit.dll not exists in the final release
> of 2008.

We just finished the conference call.

The issue with qedit.dll not being in W2k8 server is one that the dshow
team is aware of. They couldn't commit that it will be in the release
version but they are looking into whether it can be done. It may be part
of an extra component rather than part of the standard install.

They appreciated getting feedback on this issue as it helps them make the
case for qedit.dll being a component that can be installed on Windows 2008
Server.

Alessandro Angeli

unread,
Nov 1, 2007, 12:09:35 PM11/1/07
to
From: "rk"

> Alessandro thanks for this helpful hint, but i don't know
> if SampleGrabber is the only filter i need from this dll.
> It was the first error that occured, and after copying
> the Vista dll the app works. It is possible that another
> error appears after developing a custom SampleGrabber ...

qedit.dll contains DES stuff. Basic DirectShow is all in
quartz.dll.

> 1. I'm not DirectX developer, i am developer that uses
> DirectX

You do not need to know anything about DX to write a sample
grabber filter. You only need to know how to build a
VisualC++ project (the BaseClasses in the SDK) and how to
inherit a C++ class.

> 2. The samplegrabber is embedded in 3rd party components

You can still make it work with enough COM magic.

> 3. I've never used the DirectX SDK for developing, so it
> will take some time to develop such a filter

1 hour if you know what you are doing, 1 day otherwise.

> 4. I've to do a lot of work, just for get compatiblity
> for an "old app"

The more stuff you embed, the fewer compatibility problems,
since you will not have to rely on other people's choices.

> 5. We have to do a lot of tests
> 6. We've different installtions for XP,Vista,2003 <-> 2008

The embedded grabber will work on all of them, you don't
need different builds.

> 7. This could break our xopy deployment, because i think
> we've to register this custom samplegrabber in the
> registry.

You can use filters without registering them, even if the
code that tries to use them is not aware that they are not
registered.

The March Hare [MVP]

unread,
Nov 1, 2007, 12:20:37 PM11/1/07
to
On Thu, 1 Nov 2007 12:09:35 -0400, Alessandro Angeli wrote:

> qedit.dll contains DES stuff. Basic DirectShow is all in
> quartz.dll.

IIRC, IMediaDet is part of qedit.dll too.

rk

unread,
Nov 1, 2007, 12:45:01 PM11/1/07
to
> The issue with qedit.dll not being in W2k8 server is one that the dshow
> team is aware of. They couldn't commit that it will be in the release
> version but they are looking into whether it can be done. It may be part
> of an extra component rather than part of the standard install.
>
> They appreciated getting feedback on this issue as it helps them make the
> case for qedit.dll being a component that can be installed on Windows 2008
> Server.

Thanks for your support, this gives me some hope ...

rk

Alessandro Angeli

unread,
Nov 1, 2007, 12:37:59 PM11/1/07
to
From: "The March Hare [MVP]"

>> qedit.dll contains DES stuff. Basic DirectShow is all in
>> quartz.dll.
>
> IIRC, IMediaDet is part of qedit.dll too.

If you mean MediaDet :-P that's in qedit.dll because it is
part of DES.

rk

unread,
Nov 1, 2007, 12:59:03 PM11/1/07
to
Alessandro,

thanks for your comments.

It is good to know that there is way, that gives us the possibility to make
our app compatible with W2k8 without qedit.dll.

But C++ and COM are two things that i do not prefer ... and that means
before i start with such a solution i must get massive under pressure from
our customers.

The result will be, that we won't recommend Windows 2008 for our customers,
if qedit.dll is not part of it. This will work for us as long as Windows 2003
is available.

rk

Alessandro Angeli

unread,
Nov 1, 2007, 2:09:26 PM11/1/07
to
From: "rk"

> But C++ and COM are two things that i do not prefer ...
> and that means before i start with such a solution i must
> get massive under pressure from our customers.

You can do it in .NET or any other COM-aware envirinment and
the required COM knowledge is very limited.

The March Hare [MVP]

unread,
Nov 2, 2007, 9:17:55 PM11/2/07
to
On Thu, 1 Nov 2007 12:37:59 -0400, Alessandro Angeli wrote:

>> IIRC, IMediaDet is part of qedit.dll too.
>
> If you mean MediaDet :-P that's in qedit.dll because it is
> part of DES.

Well, technically IMediaDet is part of MediaDet which is part of qedit.dll,
correct? :)

Alessandro Angeli

unread,
Nov 2, 2007, 11:38:13 PM11/2/07
to
From: "The March Hare [MVP]"

>> If you mean MediaDet :-P that's in qedit.dll because it


>> is part of DES.
>
> Well, technically IMediaDet is part of MediaDet which is
> part of qedit.dll, correct? :)

Maybe it's just me, but I consider only classes aka actual
code as being part of a library, while interfaces are just
definitions, aka metadata aka syntactic glue for a
compiler/linker possibly related to or embedded in the
library but not actual code in the library and no more part
of the library than the library's documentation is.

rk

unread,
Dec 11, 2007, 4:38:01 AM12/11/07
to
> We just finished the conference call.
>
> The issue with qedit.dll not being in W2k8 server is one that the dshow
> team is aware of. They couldn't commit that it will be in the release
> version but they are looking into whether it can be done. It may be part
> of an extra component rather than part of the standard install.
>
> They appreciated getting feedback on this issue as it helps them make the
> case for qedit.dll being a component that can be installed on Windows 2008
> Server.

Thank you very much for your support !!! qedit.dll is available with RC1.

Ralf

The March Hare [MVP]

unread,
Dec 11, 2007, 9:27:11 AM12/11/07
to
On Tue, 11 Dec 2007 01:38:01 -0800, rk wrote:

> Thank you very much for your support !!! qedit.dll is available with RC1.

Thank you for reporting back that it is in W2K8 RC1. Your information was
part of the dshow team's case for getting in back in the release :)

0 new messages