|
Hear Hear
|
|
|
|
|
There's no doubt that this a brilliant idea
To hell with all the nay-sayers!
Anon
|
|
|
|
|
I have so much RAM it doesnt matter any way
********************
* $TeVe McLeNiThAn
********************
|
|
|
|
|
I have new respect for C# because of this utility.
|
|
|
|
|
Hi,
This is about Command Prompt Explorer Bar 1.1
First of all let me congratulate you for a very handy and nice application.
I am having a problem installing it on my machine, running Windows 2000 SP2.
A message pops up saying:
" This installation package cannot be installed by the windows installer service. You must install a Windows service pack that contains a newer version of the Windows Installer service".
Well, not to say I have not tried, I just went to the Microsoft website and downloaded the latest Service Pack, but I still get the same message.
What could be my problem ?
Thanks for your time.
Cheers,
M2Q
|
|
|
|
|
|
Thanks Anatol!
I will give it a try.
Cheers,
M2Q
If there's a will, there's a way!
|
|
|
|
|
First, this is a really cool tool. I love having it.
However, when I shut down/restart my computer, a dialog comes up saying explorer.exe won't shut down, and it must be killed. I think this is related to the command prompt extension because the icon on the dialog is the same as the command prompt, and it doesn't happen when i shut down without first accessing the extension at least once.
Any idea what a fix for this would be?
Again, really cool tool!
Justin Bailey
justinb.nospam@bnj.com
remove .nospam to email me!
|
|
|
|
|
Quick question. Does this work on NT4? I've gotten it to work in Windows XP Pro.
On NT4 (With IE6.0 + Active Desktop) the CommandBar Explorer Bar shows up, but the command prompt window opens as explorer.exe and it does not attach itself to the Explorer Bar. As soon as you close the "command promt" window, explorer.exe closes down, thus closing, well, the explorer.exe process.
.NET Framework + SP1 is installed. I've tried re-installing.
Any ideas, or is this just not meant to be for NT4??
Also. Is there any way to force CommandBar to automatically open every time you open Windows Explorer instead of having to press Ctrl-M every time?
|
|
|
|
|
I use your program in XP;
where can I find the C# framkwork to install
|
|
|
|
|
you can download the .NET framework from the microsoft site
"When a friend hurts us, we should write it down in the sand, where the winds of forgiveness get in charge of erasing it away, and when something great happens, we should engrave it in the stone of the memory of the heart, where no wind can erase it" Nish on life [methinks]
"It's The Soapbox; topics are optional" Shog 9
|
|
|
|
|
Command Prompt Explorer Bar Link for version 1.1 doesn work, please fix it.
|
|
|
|
|
I understand that it was a nice example of C# coding... And probably good lesson for others...
And I congratulate you on that implementation...
However, why anybody would consider loading extra 32MB of runtimes into Explorer, for the reason of seeing DOS window???...
As well as why would I need .NET framework installed on the client for doing that???...
And what is here that is impossible to implement through MFC/ATL/straight COM implemenataions???...
Everything else is looking good...
Molodec!!!...
|
|
|
|
|
Because soon enough most applications will be written in such a way that they require the .NET framework so making use of it in this little gem makes perfect sense.
|
|
|
|
|
Man, you are completely out of reality, flying somewhere in a hyped world!!!...
Just open latest MSDN (July 2002) and on page 133, first paragraph at the top, written by Paul Dilascia:
"... Of course, no programmer in his right mind would use .NET to write a console app, except as a learning exercise. That would be like firing up the space shuttle to get groceries. Did you ever notice the "net" in .NET? That means .NET is aimed at Web apps, where a few bazillion extra CPU cycles is nothing among friends, and gigabyte servers can be preloaded up the wazoo..."..
So, if it "makes perfect sense" to you -- you are free to use it... However, doesn't look like MSFT agrees with it...
|
|
|
|
|
igor1960 wrote:
Of course, no programmer in his right mind would use .NET to write a console app
He didn't use it to write a console application, he used it to write a COM server application.
igor1960 wrote:
Did you ever notice the "net" in .NET? That means .NET is aimed at Web apps,
If that was the case why the hell is there so much included for desktop apps? Don't believe everything that MS marketting leads you to. .NET was COM+ 2.0, it was NGxx (forgot the letters, next generation....), it IS a new programming platform.
igor1960 wrote:
where a few bazillion extra CPU cycles is nothing among friends
I'm beginning to think that Paul Dilascia doesn't work for MS and is an independant author. Tests have shown (refer to the DOTNET mailing list archives) that the JIT compilation will produce code that runs between 80-90% the speed of optimized C++ code.
This means that on average 11-25% more cpu instructions are spit out by the JIT compiler than the C++ compiler (assuming all cpu instructions take equal time, which they don't). I'd say thats pretty damn good considering its a first generation compiler.
James
|
|
|
|
|
James, with all due respect:
>>
He didn't use it to write a console application, he used it to write a COM server application.
<<
That's exactly my point => it's not even "console application" => it's just inproc "COM server application"... So, why should it be done in .NET???
>>
If that was the case why the hell is there so much included for desktop apps? Don't believe everything that MS marketting leads you to. .NET was COM+ 2.0, it was NGxx (forgot the letters, next generation....), it IS a new programming platform.
<<
So, much is included for desktop apps -- just to be able to convert current Java and VB client programmers to .NET... Main purpose of .NET is Server site developments... If you don't beleive me on that: just explain to me recent drop by MSFT of support of COM Interop for ActiveX on the .NET... Only, IPersistPropertyBag interface works because it's needed by IE: all other persistent intearfaces are declared but not working: and there is no attempts on MSFT site to fix it!!!... WebBrowser model is not exposed through any namespace, cause it's simply can't be exposed without rewriting WebBrowser using Managed code: and MSFT is not planning to do that... So, MSFT is serious about .NET on the Client????!!! And you don't have doubts????... Good for you then... However, I have szerious doubts...
>>
I'm beginning to think that Paul Dilascia doesn't work for MS and is an independant author. Tests have shown (refer to the DOTNET mailing list archives) that the JIT compilation will produce code that runs between 80-90% the speed of optimized C++ code.
<<
Or sure => DOTNET mailing list is the best place to get not biased view on DOTNET environment... But even if I agree with your statement that "JIT compilation will produce code that runs between 80-90% the speed of optimized C++ code", the next question would be to ask: OK, if JIT compilation will produce very fast code -- does that mean that COMPILATION ITSELF doesn't have any overhead??? You mean, compilation is SO FAST that we can exclude it from the picture???... Also, extra presence of JIT Compiler in memory is of no significance????... And finally: so decrease of 10-20% in speed for no reason is not important????....
Good Luck, James
I
|
|
|
|
|
Anyone telling you that Microsoft .NET is built mainly for building server software is telling you a lie. The Microsoft .NET Framework is built to create a whole new enviroment to do applications development on Windows, it's built to enable an uniform platform for any kinds of Windows application, be it; ASP.NET Web Forms, Web Services, Windows Forms applications, Console apps, Windows Services and Components.
Many corporations are already deploying Windows Forms based application either internally or to their customers, there are many commercial component packages built on .NET (both client and server), and there are even beginning to come out full-blown applications built on .NET
Resource requirements are something taken into consideration when your working on a project, it's all about give and take. Many companies are looking into .NET and seeing the power and richness they gain from it, there will always be C++ based solutions .. no doubt about that, but .NET is a very nice upgrade for developers and it will be widely used both on the desktop and server.
DirectX 9 will come with full .NET support with managed classes which will make it even easier to work with DX than it's already is, and it will be within 95% of the performance of C++
You can just keep on telling yourself .NET has nothing to do on the desktop, just as long as you don't tell it to others
/Sondre
|
|
|
|
|
CareBear,
I came to that country from Communist Russia... Somehow, your message reminds me of one of many Communist Speeches back in the country of my origin...
I was making TECHNICAL points, however, still can't find even 1 technical point in your message...
When you are talking about DirectX => sure it will be within 95% of C++ performance, cause it's 100% COM object implemented in C/C++/Asm... So, it has nothing to do with .NET... You will lose 5% probably on COM Interop and therefore performance would be 95%(and not 100)...
So, saying that DirectX 9 will come with full .NET support is an IGNORANT statement, that of cause can be used for MARKETING HYPE and/or other POLITICAL REASONS... It's the same as saying:
"Next version of your CD-ROM Driver will come with full .NET support with managed classes which will make it even easier to work with DX than it's already is, and it will be within 95% of the performance of C++ ".
I've never said that .NET has nothing to do on the desktop:
What I said => .NET components shouldn't be used as part of a system level, cause they introduce alot of not needed overhead...
At the end, I want to congratulate you, however, you have absolutely all qualities to be as a minimum a manager, and as a max you can even run for president...
GL
I
|
|
|
|
|
DirectX is a failure. It is supposed to get you away from hardware specifics. In practice, your app will work fine on your computer and will crash on someone else's computer.
DirectX was supposed to provide through software what wasn't done by hardware. That's false. Many basic features such like several blitting IDirectDraw modes are hardware only, or software only.
And I swallow a small raisin.
|
|
|
|
|
I have to agree with you Igor. James has very strong technical skills, but is too much headed down into MS sh*t. I am not sure I have seen from him a single point about what customers and developers really want.
And I swallow a small raisin.
|
|
|
|
|
James T. Johnson wrote:
I'd say thats pretty damn good considering its a first generation compiler.
Actually, no. MS JDK 3.0 (1997) with built-in JIT compiler.
And I swallow a small raisin.
|
|
|
|
|
StephaneRodriguez wrote:
MS JDK 3.0 (1997) with built-in JIT compiler.
That's a Java Developers Kit. The .NET compiler is first generation. Do you understand the difference between the two?
David Stone
But Clinton wasn't a predictable, boring, aging, lying, eloquent, maintainer-of-the-status-quo. He was a predictable, boring-but-trying-to-look-hip, aging-and-fat-but-seemingly-oblivious-to-it, lying-but-in-sadly-blatant-ways, not-eloquent-but-trying-to-make-up-for-it-by-talking-even-more, bringer-in-of-scary-and-potentially-dangerous-new-policies. And there was also Al Gore. It just wasn't *right*.
Shog9
|
|
|
|
|
Re-read my post mate. There is no need to tell me that MS JDK3.0 is a Java developer kit. I have said that the .NET framework is the rebranded MS JDK3.0. It should be obvious to you if you have practiced Visual J++ a couple of years ago.
And I swallow a small raisin.
|
|
|
|
|
Why do you think the command prompt is used only for running .NET apps?
There's a hell lot of 'other' things you can do with the command prompt!
Anon
|
|
|
|
|