|
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
|
|
|
|
|
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...
|
|
|
|
|