|
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
|
|
|
|
|
Hi,
I haven't experienced the same memory issues as you. I develop on Windows 2000 and Windows XP. As an informal test I've compiled a small Windows Forms app on my Windows 2000 box with a menu bar and an OnPaint() routine which displays a scaled bitmap. This uses a few assemblies more than a typical Hello World app, but the memory footprint is between 5 and 6 MB depending on whether it is a Debug or Release build. Compiling it to native code shaves a few K off this, too, and makes it a bit faster. Even loading up Web Matrix (see www.asp.com), a massive ASP.NET development environment from MS, takes up 27MB, still 5 meg leaner than your suggested minimum. These figures are from a cold-booted system, so I'm assuming no libraries are retained in memory. I can't explain the differences with your figures, but please let me know if you find out.
I think running ngen is a valid step for a program like the Command Prompt one, which is specifically tied in to Windows. For more general programs which could feasibly run on a variety of platforms you can run ngen as a step in the installation process on the client machine, getting the benefit of speed and portability.
The ability to have different versions of assemblies side by side is vital to creating a robust environment over time. Programs by default target the latest versions, but can be configured simply to run with an older version if the newer one breaks compatibility. This avoids the main cause of DLL Hell. One would hope that Microsoft gets all its releases correct, but having the core assemblies versioned as well means that even if they do get it wrong and break your old program, you can distribute a simple XML config file to your clients to fix it without having to rebuild. I believe MFC programmers have experienced this problem sometimes when new versions are released. Luckily because the assemblies are quite finely grained, updates do not have to be massive if only a few changes are required.
I think we will see many Windows Forms applications being released in the coming months, by MS and independent vendors. Updates and bug fixes can be much quicker thanks to the development environment and the FCL being so mature and rich for a version 1.0 product. We'll see what happens, but it's still great to have the choice no matter what your preferred environment is
Cheers,
Dave
|
|
|
|
|
Dave, it's very important to spell the same technique we are using to calculate memory footprint... I would love to know, how you achieve that...
My statistic is based on all CRL modules loaded with preallocated default heap without any stress on the system... Meaning, you just start WinForm app and without minimizing go to Task Manager and see how much memory was allocated...
If you are talking about 5-6MB of allocated memory under stress and when your program is on the background, and or minimized => yes sure... When some program does nothing it's ideally memory consumption should go to 0, isn't it???...
So, let me know how much memory you see after your WinForm App just started and being active...
GL
I
|
|
|
|
|
Hi,
The technique I used was to reboot Windows 2000, open Task Manager immediately, then run the application from the command line. While the Task Manager was still on screen, I manipulated the program, which should have called the JITter on it and loaded any additional resources into memory. I kept a note of the maximum memory usage by looking at the reading in the 'Processes' tab of Task Manager in real time, and also by calculating the difference between the Total Memory Usage before and during the program's run. I did the same thing for my small Windows Forms app and the (rather larger!) Web Matrix application.
I haven't changed my Visual Studio .NET setup since installation. Both apps were compiled in Release mode.
It would be interesting to hear of anybody's else's experience in this matter. It may be that a particular selection of assemblies have a far larger footprint than others. Also it would be really useful to drill down into the Process and get an idea how much code each part of the runtime takes up, but I haven't found anything that does this yet.
Cheers,
Dave
|
|
|
|
|
The Task Manager "Mem usage" is not reliable. Only "VM usage" is.
And I swallow a small raisin.
|
|
|
|
|
Dave, I also forgot to mention one more thing specific to COM Interop that is privately acknowledged by MSFT .NET team during my company and MSFT common project... According to MSFT, just COM Interop memory consumption between WebBrowser and any .NET Control inside of it is ~12MB... Just thought might be of interest to you and maybe something you could clarify for yourself if in doubt...
Again,
Regards
I
|
|
|
|
|
My numbers - 22,204 for a pretty complex managed C++ app. This is doing COM interop (it starts the MSJVM... don't ask) and runs a 3D DX7 based rendering engine.
IMHO .NET is good stuff. Some oddities, but for a 1.0 product not bad. And the time it saves in UI programming... 
|
|
|
|
|
microsoft first introduce ole
then com
then dcom
then com+
then .net
techonlogies for making programer live more easy.
i bet that .net it will be in windows by default like mfc is
so why will we stress now in a couple of years you will see .net desktop aplication as ofen as you see today mfc aplication so...
|
|
|
|
|
Before I read the complete thread - it was as quite clear that we had a Russian here, a self opinionated, self obsessed individual I've worked for many a year in the industry and have yet to come across a Russian who isn't looking for argument believes he/she is superior after leaving there 'wonderful' country (and let me say it is)
A little respect unfortunately people here have different opinions and different needs were not all industry leaders, oh were can I read anything you've published other than this diatribe?
|
|
|
|
|
Serious sh*t of you, many things he says are right and detailed, which is much more uncommon from people like you and MS advocates...
And I swallow a small raisin.
|
|
|
|
|
Hey, IDIOT: Original article and system was written by Russian too... So, what's your point?...
BTW: Your racist remarks just confirm who is more "opinionated" among us!
Just goto hell...
|
|
|
|
|
I'm thrilled to have this utility rather than launching a separate command window each time I wish to perform a command line task in a folder, but I am concerned about efficiency, so if anyone could answer this it might put my mind at ease. When I install this component and run Explorer, at that point has .NET been invoked and is the memory consumption greater than if I hadn't installed the bar? In other words, prior to actually hitting Ctrl-M, what is the footprint of a registered explorer bar, if any?
Thanks!
James
|
|
|
|
|
Pretty funny reading this comments 6 years later while .NET has matured so much and there are so many companies and private developers using .NET.
|
|
|
|
|
"Well, that is how it looks like. Isn't it a beauty?" 
Normski. - Professional Windows Programmer
|
|
|
|
|
Very cool. Can't believe I haven't seen something like this before, sure kicks the crap out of the "Cmd prompt here" menu hack!
|
|
|
|
|
Hi,
I'm working on a Browser Helper Object and want to add a hotkey (I'm using atl/mfc, not .NET). I can get the hotkey to appear in the explorer bars menu of IE easily enough, but it doesn't do anything!
Is there a registry entry I need to add / set somewhere to let IE know about the hotkey?
Thanks!
Chris
|
|
|
|
|
Hi Chris.
Well, the way I doing it is through Windows Hooking (SetWindowsHookEx). You can see CtrlMHook class in my source code. Although it is in C# it is pretty much the same way you can do this in C++(just get rid of DllImport and delegates stuff). I think there should be some C++ example available, KBBar or something. When you say you can 'get the hotkey to appear in the explorer bars menu' what do you mean ? Can I benefit from you knowledge  ?
P.S. About the registry, I think I was looking pretty hard(with regmon) and didn't find anything.
Thanks,
Pavel.
|
|
|
|
|
Hi Pavel.
You're work is fantastic. However, since I am not using plain vanilla cmd.exe but 4NT [Paul], I would like to see an option to change the used command processor (which is cmd.exe by default).
Regards
Thomas
Sonork id: 100.10453 Thömmi
Disclaimer:
Because of heavy processing requirements, we are currently using some of your unused brain capacity for backup processing. Please ignore any hallucinations, voices or unusual dreams you may experience. Please avoid concentration-intensive tasks until further notice. Thank you.
|
|
|
|
|
Hi Thomas,
Just tested it with 4NT401 – looks good. It will be probably a couple of days until update 1.2 ready. Want to bring nice Options dialog. So if you are in a hurry you can modify ConsoleCtrl.OpenConsole() yourself:
<br />
bool b = Win32.CreateProcessW( <br />
null,<br />
@"c:\4nt401\4nt.exe",<br />
IntPtr.Zero,<br />
IntPtr.Zero,<br />
false,<br />
0x0400400,<br />
IntPtr.Zero,<br />
null,<br />
si,<br />
pi );<br />
Nice suggestion, thanks,
Pavel.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
