|
|
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
|
|
|
|
|
LOL! 32 mb of runtime files does NOT mean 32 mb of ram taken up during execution of a program written to utilize it, you know.
|
|
|
|
|
Actually, Anonymous: Before posting you better check yourself...
.NET CRL is just 12MB of runtime (on disk) => However, after loading into RAM it's 32MB...
So, you should know that => at least before posting here and not after...
Also, just to make your life even more miserable: Each .NET component is linked with particular version of .NET Framework... That just means, that when MSFT releases next version of .NET you either have to rebuild your program to link to the latest one and redistribute to your clients... Or which is more probable: Your CLIENTS will be forced to have several versions of the framework: Latest one and the one your program was build against...
So, that means that you may finish with far more then 12mb of runtimes on disk...
GL
I
|
|
|
|
|
this guy sounds like he knows whats he talking about... hehe, i wouldnt mess wit him, dude did his homework.
|
|
|
|
|
Hi,
By default .NET exes will link to the latest version of dependent assemblies, yours or Microsoft's. Your programs will work when Microsoft updates its core libraries no problem (and one would think that there would be a performance improvement too). Of course, if you _need_ to use a particular version of an assembly, you can set this when compiling your program (by strongly naming the assembly and placing it in the GAC) or override this on an assembly-by-assembly basis in 'Control Panel->Administrative Tools->.NET Framework Configuration' on the Client if there is a post-release issue. Assembly control is very fine grained and powerful in .NET.
Also please note that the .NET runtime environment does not load assemblies into memory until they are used, so the memory footprint is not constant.
In a previous post you also mentioned the runtime impact of JIT compiling code. Running the 'ngen' tool on your exe will precompile it so this step can be skipped on the client.
I'm writing desktop apps, and finding the .NET environment a pleasure to use, especially the FCL. Performance is not as good as pure Win32 code, but I didn't expect it to be. Future releases of the compilers and core assemblies will improve this, but even now it is far superior to Java IMO.
Regards,
Dave
|
|
|
|
|
Dave, thanx for more in depth look into that issue...
No question about pleasure of usage and etc... And no questions that it's far superior to Java...
I've dicovered however that memory footprint is almost constant, independent of whether you are loading just small "Hello World" program or full blown WinForm App => and it starts at around 32MB... If you have different statistics, please let me know...
While you have an option of running 'ngen', as you mentioned, will make your code not movable to other JIT implementations, isn't it???...
As to parallel Framework installations, even if yopu deside to use latest -- nothing in the .NET framwork takes care of removing old versions -- meaning exactly what I was saying -- you will finish up with much more disk space wasted by old Framework modules that will never be used...
Absolutely agree with you that for development distributed client site applications .NET is of great value -- however having about 20 years of experience in programming, among which 12 in MFC and 7 in ATL: I strongly beleive that for pure Desktop solutions, like System/Graphics/CAD/CAM -- business logic is much more important and more time and development consuming then anything addressed by .NET....
Regards,
Igor
|
|
|
|
|