|
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.
|
|
|
|
|
Pavel Zolnikov wrote:
Nice suggestion, thanks,
It's sheer selfishness
Pavel Zolnikov wrote:
Want to bring nice Options dialog.
Wow. I am looking forward to it
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.
|
|
|
|
|
I myself am used to using a TCSH for windows that runs inside the cmd.exe. Is this something that can be handled? Usually I run a batch file that opens my shell. Batch file looks like:
@echo off
title TCSH shell
call D:\Softimage\XSI_2.0.1\Application\bin\Setenv.bat
call I:\SHAKE\Shake-v2.46\init.bat
set Path=I:\TCSH_for_NT;I:\Shake\Shake-v2.46;%Path%
echo Environments are set for XSI 2.0.1 and Shake 2.46
set HOME=U:
cmd /C call I:\TCSH_for_NT\tcsh.exe
echo on
|
|
|
|
|
How about
bool b = Win32.CreateProcessW(
null,
"<span style="color:#af0000;">%comspec%</span>",
IntPtr.Zero,
IntPtr.Zero,
false,
0x0400400,
IntPtr.Zero,
null,
si,
pi );
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.
|
|
|
|
|
Absolutely outstanding thing here!!!
I've wished for something like this ever since I used Win95!!! (several years that is.)
Thank you!!! Thank you!!! Thank you!!!
Give me your adress, and I'll send you some money!
Best regards from Hugo Hallman.
|
|
|
|
|
I have tried to install it with the latest update (1.1) and I keep getting the following error:
An exception occurred during the Commit phase of the installation. This exception will be ignored and installation will continue. However, the application might not function correctly after installation is complete. --> Access to the registry key is denied.
After this the progress bar goes backwards and appears to roll back the installation eventhough it claims the installation was successful.
After installation the binaries are not to be found on my disk. Instead the destination directory contains installer.installstate and two .tmp files.
I am on Win2000 professional and have administrator priviliges.
Please advise,
Rex
|
|
|
|
|
Ok, now it is weird again . I recommend going to http://www.sysinternals.com downloading their regmon – wonderful tool by the way – and running it just before running setup. In Filter dialog set Include to msiexec.exe. After setup is done, you can save registry access operations history into a log file. See if you can find some failing. I would also appreciate a chance to look at this log.
|
|
|
|
|
Пятёрочка.
Ждём версии без .NET -
Translation -
Excellent - looking forward for a version with no .NET
|
|
|
|