Does anyone use regdmp.exe or objdir.exe?

What would be the impact on you if we pulled regdmp.exe and objdir.exe from
the WDK?

David
Wed Apr 18 16:58:34 CDT 2007

The fact that MSJAVA.DLL is not available so objdir.exe can be used is a
problem with the 6000 build. The two other object tree browsers from OSR
and Sysinternals (Microsoft) are both GUI applications. The old working
objdir.exe was command line and would permit it to be used from scripts.
That is about the only problem I see with eliminating it from the WDK. I
prefer resplendent registrar for registry editing, but a command line dumper
can be used in automated testing to check if the registry was updated
correctly by some component or install.

I guess the elimination of command line tools seems to be wave of the
future, but they are useful and Microsoft should see if suitable
replacements are available. The more testing that can be automated, the
more testing that will be done.

"Jennifer Stepler [MSFT]" <JenniferSteplerMSFT@discussions.microsoft.com>
wrote in message news:D3BE8F62-81FE-4C0A-B45D-C40275C3C8E0@microsoft.com...
> What would be the impact on you if we pulled regdmp.exe and objdir.exe
> from
> the WDK?

JenniferSteplerMSFT
Wed Apr 18 17:18:00 CDT 2007

David,
Thanks for your feedback. We are strong supporters of automated testing.
I'll pass this along.
Jennifer

"David Craig" wrote:

> The fact that MSJAVA.DLL is not available so objdir.exe can be used is a
> problem with the 6000 build. The two other object tree browsers from OSR
> and Sysinternals (Microsoft) are both GUI applications. The old working
> objdir.exe was command line and would permit it to be used from scripts.
> That is about the only problem I see with eliminating it from the WDK. I
> prefer resplendent registrar for registry editing, but a command line dumper
> can be used in automated testing to check if the registry was updated
> correctly by some component or install.
>
> I guess the elimination of command line tools seems to be wave of the
> future, but they are useful and Microsoft should see if suitable
> replacements are available. The more testing that can be automated, the
> more testing that will be done.
>
> "Jennifer Stepler [MSFT]" <JenniferSteplerMSFT@discussions.microsoft.com>
> wrote in message news:D3BE8F62-81FE-4C0A-B45D-C40275C3C8E0@microsoft.com...
> > What would be the impact on you if we pulled regdmp.exe and objdir.exe
> > from
> > the WDK?
>
>
>

Maxim
Thu Apr 19 01:25:12 CDT 2007

I'm strictly against this.

This will end the person trying to find some ancient DDKs from historical
MSDN shipments to find the tool.

I'm very much against any tool removal from the DDK, especially
command-line tool removal in favour of GUI ones. Retain both.

Unsupported and undocumented (except the stdout usage prompt) tools are
much better then removed tools. So, I would suggest that MS would move the
tools to "unsupported" category instead of dropping them completely.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Jennifer Stepler [MSFT]" <JenniferSteplerMSFT@discussions.microsoft.com> wrote
in message news:D3BE8F62-81FE-4C0A-B45D-C40275C3C8E0@microsoft.com...
> What would be the impact on you if we pulled regdmp.exe and objdir.exe from
> the WDK?

JenniferSteplerMSFT
Thu Apr 19 14:48:01 CDT 2007

Can you use reg.exe, which is part of the OS, as a substitute for regdmp.exe?
If not, what do you need from regdmp.exe that you don't get from reg.exe?

Thanks,
Jennifer


"David Craig" wrote:

> The fact that MSJAVA.DLL is not available so objdir.exe can be used is a
> problem with the 6000 build. The two other object tree browsers from OSR
> and Sysinternals (Microsoft) are both GUI applications. The old working
> objdir.exe was command line and would permit it to be used from scripts.
> That is about the only problem I see with eliminating it from the WDK. I
> prefer resplendent registrar for registry editing, but a command line dumper
> can be used in automated testing to check if the registry was updated
> correctly by some component or install.
>
> I guess the elimination of command line tools seems to be wave of the
> future, but they are useful and Microsoft should see if suitable
> replacements are available. The more testing that can be automated, the
> more testing that will be done.
>
> "Jennifer Stepler [MSFT]" <JenniferSteplerMSFT@discussions.microsoft.com>
> wrote in message news:D3BE8F62-81FE-4C0A-B45D-C40275C3C8E0@microsoft.com...
> > What would be the impact on you if we pulled regdmp.exe and objdir.exe
> > from
> > the WDK?
>
>
>

JenniferSteplerMSFT
Thu Apr 19 14:54:01 CDT 2007

Hi Max,
Unfortunately, some of these old tools violate Microsoft legal obligations
under the anti-trust consent decree. They would need to be reworked if we
want to continue to ship them. We're trying to determine if they are worth
the effort or if we should use those resources for newer development tools.

If we remove a tool, would the users of that tool just go get it from a
prior kit?

Thanks,
Jennifer

"Maxim S. Shatskih" wrote:

> I'm strictly against this.
>
> This will end the person trying to find some ancient DDKs from historical
> MSDN shipments to find the tool.
>
> I'm very much against any tool removal from the DDK, especially
> command-line tool removal in favour of GUI ones. Retain both.
>
> Unsupported and undocumented (except the stdout usage prompt) tools are
> much better then removed tools. So, I would suggest that MS would move the
> tools to "unsupported" category instead of dropping them completely.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
> "Jennifer Stepler [MSFT]" <JenniferSteplerMSFT@discussions.microsoft.com> wrote
> in message news:D3BE8F62-81FE-4C0A-B45D-C40275C3C8E0@microsoft.com...
> > What would be the impact on you if we pulled regdmp.exe and objdir.exe from
> > the WDK?
>
>

Maxim
Thu Apr 19 15:01:16 CDT 2007

Prior kit will be very hard to find. I think that Win98 DDK was removed due
to the very same legal issues, and it's a pity, since it is the last DDK which
contains the very good technology of Video for Windows, which allows to write
the virtual video camera drivers _without ever touching the kernel_.

For now, people are going in for kernel to write a virtual video camera
driver, which is a bad idea is think.

Yes, DirectShow is user-mode-only (does not mandate the kernel code), and
DirectShow filter is OK - but sorry, it is too hard, requires some
boilerplate - then why not continue the good old Video for Windows technology,
since in this case the "DirectShow boilerplate" is automatically provided by
the OS as QCAP.DLL?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Jennifer Stepler [MSFT]" <JenniferSteplerMSFT@discussions.microsoft.com> wrote
in message news:B330F1B6-2D7F-42EC-8E71-6B797103359E@microsoft.com...
> Hi Max,
> Unfortunately, some of these old tools violate Microsoft legal obligations
> under the anti-trust consent decree. They would need to be reworked if we
> want to continue to ship them. We're trying to determine if they are worth
> the effort or if we should use those resources for newer development tools.
>
> If we remove a tool, would the users of that tool just go get it from a
> prior kit?
>
> Thanks,
> Jennifer
>
> "Maxim S. Shatskih" wrote:
>
> > I'm strictly against this.
> >
> > This will end the person trying to find some ancient DDKs from
historical
> > MSDN shipments to find the tool.
> >
> > I'm very much against any tool removal from the DDK, especially
> > command-line tool removal in favour of GUI ones. Retain both.
> >
> > Unsupported and undocumented (except the stdout usage prompt) tools are
> > much better then removed tools. So, I would suggest that MS would move the
> > tools to "unsupported" category instead of dropping them completely.
> >
> > --
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > maxim@storagecraft.com
> > http://www.storagecraft.com
> >
> > "Jennifer Stepler [MSFT]" <JenniferSteplerMSFT@discussions.microsoft.com>
wrote
> > in message news:D3BE8F62-81FE-4C0A-B45D-C40275C3C8E0@microsoft.com...
> > > What would be the impact on you if we pulled regdmp.exe and objdir.exe
from
> > > the WDK?
> >
> >

David
Thu Apr 19 15:26:04 CDT 2007

It does appear to work well enough to be useful. I had not noticed it
before as I only used regedit and regedt32. I had not tried to do a
registry check as I suggested using Python to validate appropriate values
being created. The output can reg.exe can be redirected - I tested it and
it works well. Maybe some documentation in the WDK on the parameters to it
or a link to its documentation.

If you wanted to help the developer community, you could add a piece on
installing some device such as the Toaster device. Then have a script
sample that would use reg.exe to dump the output of that
HKLM\SYSTEM\CurrentControlSet\Services\Toaster key and have a Windows script
compare the values dumped against expected values. That one sample would
give a lot to the QA community.

"Jennifer Stepler [MSFT]" <JenniferSteplerMSFT@discussions.microsoft.com>
wrote in message news:405154A3-7AB8-453A-AB08-FE3CF1502175@microsoft.com...
> Can you use reg.exe, which is part of the OS, as a substitute for
> regdmp.exe?
> If not, what do you need from regdmp.exe that you don't get from reg.exe?
>
> Thanks,
> Jennifer
>
>
> "David Craig" wrote:
>
>> The fact that MSJAVA.DLL is not available so objdir.exe can be used is a
>> problem with the 6000 build. The two other object tree browsers from OSR
>> and Sysinternals (Microsoft) are both GUI applications. The old working
>> objdir.exe was command line and would permit it to be used from scripts.
>> That is about the only problem I see with eliminating it from the WDK. I
>> prefer resplendent registrar for registry editing, but a command line
>> dumper
>> can be used in automated testing to check if the registry was updated
>> correctly by some component or install.
>>
>> I guess the elimination of command line tools seems to be wave of the
>> future, but they are useful and Microsoft should see if suitable
>> replacements are available. The more testing that can be automated, the
>> more testing that will be done.
>>
>> "Jennifer Stepler [MSFT]" <JenniferSteplerMSFT@discussions.microsoft.com>
>> wrote in message
>> news:D3BE8F62-81FE-4C0A-B45D-C40275C3C8E0@microsoft.com...
>> > What would be the impact on you if we pulled regdmp.exe and objdir.exe
>> > from
>> > the WDK?
>>
>>
>>

David
Thu Apr 19 15:30:25 CDT 2007

I saw that with the objdir and its use of Java. Since Microsoft now owns
Sysinternals maybe their object directory dumper could have a command line
mode done. Since the OS comes with reg.exe it will work very well, but the
objdir is not replaceable, AFAIK. I am very pleased and am sure many others
are too with Microsoft beginning to ask these questions. Knowing our needs
are being considered is a very good thing.

"Jennifer Stepler [MSFT]" <JenniferSteplerMSFT@discussions.microsoft.com>
wrote in message news:B330F1B6-2D7F-42EC-8E71-6B797103359E@microsoft.com...
> Hi Max,
> Unfortunately, some of these old tools violate Microsoft legal obligations
> under the anti-trust consent decree. They would need to be reworked if we
> want to continue to ship them. We're trying to determine if they are
> worth
> the effort or if we should use those resources for newer development
> tools.
>
> If we remove a tool, would the users of that tool just go get it from a
> prior kit?
>
> Thanks,
> Jennifer
>
> "Maxim S. Shatskih" wrote:
>
>> I'm strictly against this.
>>
>> This will end the person trying to find some ancient DDKs from
>> historical
>> MSDN shipments to find the tool.
>>
>> I'm very much against any tool removal from the DDK, especially
>> command-line tool removal in favour of GUI ones. Retain both.
>>
>> Unsupported and undocumented (except the stdout usage prompt) tools
>> are
>> much better then removed tools. So, I would suggest that MS would move
>> the
>> tools to "unsupported" category instead of dropping them completely.
>>
>> --
>> Maxim Shatskih, Windows DDK MVP
>> StorageCraft Corporation
>> maxim@storagecraft.com
>> http://www.storagecraft.com
>>
>> "Jennifer Stepler [MSFT]" <JenniferSteplerMSFT@discussions.microsoft.com>
>> wrote
>> in message news:D3BE8F62-81FE-4C0A-B45D-C40275C3C8E0@microsoft.com...
>> > What would be the impact on you if we pulled regdmp.exe and objdir.exe
>> > from
>> > the WDK?
>>
>>

Dave
Thu Apr 19 18:10:26 CDT 2007

I think David has hit on the correct solution here...

*IF* ( and thats a BIG IF) you remove the old command line tools, spruce up
GUI tools to take some command line args and run without a GUI..
essentiallly give them the same functionality as the old tools.. FWIW I've
been doing this for years with tools I write for propriteary things...

And to answer your question of "will people load them from old DDK's".. Hell
yes we will...

Case in point... you decided that DirectShow was going to ship with the
Platform SDK not the DX-SDK and then in your infinite wisdom yanked out all
the Visual Studio Projects and just left makefiles.... well the whole DShow
world has been sticking the damn VS projects BACK IN from the DX9.0 SDK..
partly because you only have command line build enviornments for ansi debug
and release and a whole lot of us build unicode in the DShow world... and
yes we could cook up unicode commandline builds.. but why waste time when
the fricken VS projects exist and do the right thing....

And it REALLY "torques my main bolt" that I STILL have to have the DX-SDK to
build the Dshow stuff... I mean what was the point of THAT whole
thing????... I know The DX people look down their noses at the DS people...
It'd sure be nice if you'd get YOUR politics straight so WE can continue to
wirte programs...

THINK long and hard before you remove things, or move thing slike Dshow
around..

--.- Dave


"David Craig" <dave@yoshimuni.com> wrote in message
news:eWyWRGsgHHA.4892@TK2MSFTNGP03.phx.gbl...
>I saw that with the objdir and its use of Java. Since Microsoft now owns
>Sysinternals maybe their object directory dumper could have a command line
>mode done. Since the OS comes with reg.exe it will work very well, but the
>objdir is not replaceable, AFAIK. I am very pleased and am sure many
>others are too with Microsoft beginning to ask these questions. Knowing
>our needs are being considered is a very good thing.
>
> "Jennifer Stepler [MSFT]" <JenniferSteplerMSFT@discussions.microsoft.com>
> wrote in message
> news:B330F1B6-2D7F-42EC-8E71-6B797103359E@microsoft.com...
>> Hi Max,
>> Unfortunately, some of these old tools violate Microsoft legal
>> obligations
>> under the anti-trust consent decree. They would need to be reworked if
>> we
>> want to continue to ship them. We're trying to determine if they are
>> worth
>> the effort or if we should use those resources for newer development
>> tools.
>>
>> If we remove a tool, would the users of that tool just go get it from a
>> prior kit?
>>
>> Thanks,
>> Jennifer
>>
>> "Maxim S. Shatskih" wrote:
>>
>>> I'm strictly against this.
>>>
>>> This will end the person trying to find some ancient DDKs from
>>> historical
>>> MSDN shipments to find the tool.
>>>
>>> I'm very much against any tool removal from the DDK, especially
>>> command-line tool removal in favour of GUI ones. Retain both.
>>>
>>> Unsupported and undocumented (except the stdout usage prompt) tools
>>> are
>>> much better then removed tools. So, I would suggest that MS would move
>>> the
>>> tools to "unsupported" category instead of dropping them completely.
>>>
>>> --
>>> Maxim Shatskih, Windows DDK MVP
>>> StorageCraft Corporation
>>> maxim@storagecraft.com
>>> http://www.storagecraft.com
>>>
>>> "Jennifer Stepler [MSFT]"
>>> <JenniferSteplerMSFT@discussions.microsoft.com> wrote
>>> in message news:D3BE8F62-81FE-4C0A-B45D-C40275C3C8E0@microsoft.com...
>>> > What would be the impact on you if we pulled regdmp.exe and objdir.exe
>>> > from
>>> > the WDK?
>>>
>>>
>
>