Writing plugins using .NET
Moderators: Hacker, petermad, Stefan2, white
Writing plugins using .NET
Hello!
I'm just starting to take a look at Delphi 2005 and its .NET support. Seeing that the EXE of an almost empty project is 27kb versus 200kb for the same project using traditional Win32/VCL, I'm thinking about doing .NET stuff.
So to my question - is it possible to do a plugin for TC using .NET?
I'm just starting to take a look at Delphi 2005 and its .NET support. Seeing that the EXE of an almost empty project is 27kb versus 200kb for the same project using traditional Win32/VCL, I'm thinking about doing .NET stuff.
So to my question - is it possible to do a plugin for TC using .NET?
Best regards,
Christian Tiberg
Christian Tiberg
2ctiberg
I'm not really sure if this is a fair comparison. I you don't include the Delphi runtime into the library the size will be smaller than 200 KB I guess.Seeing that the EXE of an almost empty project is 27kb versus 200kb for the same project using traditional Win32/VCL, I'm thinking about doing .NET stuff.
That's exactly right, of corpse. The difference is that I can be relatively sure that everyone has (or can get) .NET Framework, while the same absolutely can't be said about Delphi Win32. Beeing able to leave out the runtime library has been possible for a long time, but isn't of much use if you've got one EXE/DLL and has to push the RTL into the installer anyways...Lefteous wrote:I'm not really sure if this is a fair comparison. I you don't include the Delphi runtime into the library the size will be smaller than 200 KB I guess.
Best regards,
Christian Tiberg
Christian Tiberg
If I compile e Delphi 7 project without runtime the .exe if 16.5 KB.ctiberg wrote:Lefteous wrote:I'm not really sure if this is a fair comparison. I you don't include the Delphi runtime into the library the size will be smaller than 200 KB I guess.
I don't have .NET Framework installed. OK the program is small. But you need 25MB framework and the programctiberg wrote:That's exactly right, of corpse. The difference is that I can be relatively sure that everyone has (or can get) .NET Framework, while the same absolutely can't be said about Delphi Win32. Beeing able to leave out the runtime library has been possible for a long time, but isn't of much use if you've got one EXE/DLL and has to push the RTL into the installer anyways...
execute slower and use alot more memory then a Delphi program.
Plugins that use runtime would make TC/lister start much slower.
I think a program that is complete independent runtimes is the best.
Read this blog on sysinternals:
"The Coming .NET World – I’m scared"
http://www.sysinternals.com/blog/2005_04_01_archive.html
// Peter
Last edited by petergus on 2006-02-09, 15:39 UTC, edited 1 time in total.
I have had only bad experiences with .NET Framework like applications not correctly shutting down, extensive CPU and memory usage, so I got rid of it completely. It will for sure not enter my system again until Microsoft forces me to use it and I hope they will never do.
Icfu
Icfu
This account is for sale
I should really have my arm twisted around before anybody could force me to install .NET Framework 

License #524 (1994)
Danish Total Commander Translator
TC 11.51 32+64bit on Win XP 32bit & Win 7, 8.1 & 10 (22H2) 64bit, 'Everything' 1.5.0.1391a
TC 3.60b4 on Android 6, 13, 14
TC Extended Menus | TC Languagebar | TC Dark Help | PHSM-Calendar
Danish Total Commander Translator
TC 11.51 32+64bit on Win XP 32bit & Win 7, 8.1 & 10 (22H2) 64bit, 'Everything' 1.5.0.1391a
TC 3.60b4 on Android 6, 13, 14
TC Extended Menus | TC Languagebar | TC Dark Help | PHSM-Calendar
- ghisler(Author)
- Site Admin
- Posts: 50421
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
I have it installed only for one specific program which needs it, but it reminds me somehow of the old vbrun100.dll of Visual Basic: Huge and slow. I don't think that it's really suited for writing plugins, because of the slow startup. You can do the same in plain C/C++ or Delphi, and it will be loading 1000 times faster. For such small projects as most plugins, the gain in efficiency for the developer would be minimal compared to the above mentioned languages, but the loss in speed would be very large.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
- majkinetor !
- Power Member
- Posts: 1580
- Joined: 2006-01-18, 07:56 UTC
- Contact:
First, this sound like one of the "I hate Microsoft" topics.
I hate mirosoft most of the time, but I don't have preconclusions even about Microsoft and U should also act like that. For instance, XP is excellent, you can't really tell anything against it.....
Anyway, to continue with the topic:
If program is slow it is badly designed. You can't judge platform because of that....
Next, in new MS OSes, Win API will be replaced by it's .NET successor called WinFX. No matter you like it or no, it will be there....
That said, I think TC plugins should be written using some already "tested" languages/compilers.... Remember, .NET is new beast. It is beast for near future.
I hate mirosoft most of the time, but I don't have preconclusions even about Microsoft and U should also act like that. For instance, XP is excellent, you can't really tell anything against it.....
Anyway, to continue with the topic:
.Net is young platform, and most of the things in it was created by ex Borland team leader which crated Turbo Pascal and later. .Net program executes slower just the first time, since it has to be compiled on first run. This is called "on demand compilation". The more U run the app it runs faster until its every part is compiled. After that, it is identical to normal, non .Net exe.OK the program is small. But you need 25MB framework and the program execute slower and use alot more memory then a Delphi program.
If program is slow it is badly designed. You can't judge platform because of that....
Next, in new MS OSes, Win API will be replaced by it's .NET successor called WinFX. No matter you like it or no, it will be there....
That said, I think TC plugins should be written using some already "tested" languages/compilers.... Remember, .NET is new beast. It is beast for near future.
Habemus majkam!
Here are few things Mark from Sysinternals wrote about this topic:
http://www.sysinternals.com/blog/2005/04/coming-net-world-im-scared.html
http://www.sysinternals.com/blog/2005/04/net-world-follow-up.html
http://www.sysinternals.com/blog/2005/04/coming-net-world-im-scared.html
http://www.sysinternals.com/blog/2005/04/net-world-follow-up.html
Ambiguity succeeds where honesty dares not venture.
But what about nLite, Pa?icfu wrote:I have had only bad experiences with .NET Framework like applications not correctly shutting down, extensive CPU and memory usage, so I got rid of it completely. It will for sure not enter my system again until Microsoft forces me to use it and I hope they will never do.
Icfu

Regards,
deus-ex
majkinetor !
Next runs of course, take less time, but the delay is still noticable - it's about 0,3-0,4 seconds. For so small and simple program!
Moreover, after I worked for some time with other applications like MS Word, I tried to start your program again - and it again took about 2-3 seconds to start. Where the speed increasing (that you're talking about) have gone? And what will see the users of slower machines?
In one of the topics (when discussing improvements of Copy/Move overwrite dialog) you created a simple program written (as I understand) on .NET platform. I started it couple of hours ago, and it took (on my Athlon64 3200+ computer with 1 GB RAM) 3 seconds to start this program!.Net program executes slower just the first time, since it has to be compiled on first run. This is called "on demand compilation". The more U run the app it runs faster until its every part is compiled. After that, it is identical to normal, non .Net exe.

Moreover, after I worked for some time with other applications like MS Word, I tried to start your program again - and it again took about 2-3 seconds to start. Where the speed increasing (that you're talking about) have gone? And what will see the users of slower machines?
Flint's Homepage: Full TC Russification Package, VirtualDisk, NTFS Links, NoClose Replacer, and other stuff!
Using TC 11.03 / Win10 x64
Using TC 11.03 / Win10 x64
@deus-ex:

I don't use nLite because it is still in development and after watching the changelog I simply don't trust it. It never gets done, it has to permanently fix some issue, I don't have any desires to run into problems just because another thing got "accidentally" broken.
Regarding the features:
- Service Pack Integration
> I do that myself, unattended installation.
- Component Removal
> Some things I remove during unattended installation, the rest I simply don't use but if I change my mind I know the stuff is still there.
- Unattended Setup
> I do that myself.
- Driver Integration *
> Can do that myself when I need it.
- Hotfixes Integration **
> There are hotfixes every month, so what you get here is an up-to-date nLite that is outdated one month later. Windows Update also installs hotfixes and I have a chance to remove them afterwards in case they are buggy.
- Tweaks
> God beware, nope. I prefer tweaking myself.
- Patches ***
> Can do that myself.
- Bootable ISO creation
> I can do that myself.
To sum it up:
nLite is cool if you are in the mood to experiment with your OS, maybe I will try it for fun one day.
Icfu
Alternative Runtimes v2.0, Ma?But what about nLite, Pa?

I don't use nLite because it is still in development and after watching the changelog I simply don't trust it. It never gets done, it has to permanently fix some issue, I don't have any desires to run into problems just because another thing got "accidentally" broken.
Regarding the features:
- Service Pack Integration
> I do that myself, unattended installation.
- Component Removal
> Some things I remove during unattended installation, the rest I simply don't use but if I change my mind I know the stuff is still there.
- Unattended Setup
> I do that myself.
- Driver Integration *
> Can do that myself when I need it.
- Hotfixes Integration **
> There are hotfixes every month, so what you get here is an up-to-date nLite that is outdated one month later. Windows Update also installs hotfixes and I have a chance to remove them afterwards in case they are buggy.
- Tweaks
> God beware, nope. I prefer tweaking myself.
- Patches ***
> Can do that myself.
- Bootable ISO creation
> I can do that myself.
To sum it up:
nLite is cool if you are in the mood to experiment with your OS, maybe I will try it for fun one day.

Icfu
This account is for sale
No preconceptions or 'I hate MS rants', but any .NET program will always lose out to its binary compiled counterpart because by definition the .NET framework uses a runtime-compile management strategy. This is not a million miles away from runtime interpreters like our beloved Basic.
It'll not load and run as quickly due to intermediate bytecode having to be translated to machine code on the fly, and it'll take up more memory due to the overhead caused by the supervising structure.
Any speed gains will only hold so long as the app remains loaded in memory. Reload, and you start from square one again, AFAIK.
The rationale for the .NET framework seems to be that since the just-in-time engine is 'aware' of its runtime environment, it can take steps to thwart potential problems such as memory leaks and security loopholes like buffer overruns, bad array bounds, etc.
It also claims to be platform agnostic and lays down the law according to MS for programming standards (classes, types, bla, bla - not a bad thing by any means).
Call me a cynic, but I smell a late response to the Java Development Platform.
When that became hotter than a chili-pepper a few years back, I suspect there were quite a few worried frowns in the MS camp as they watched the development initiative move away from Redmond. And so now we have .NET.
It's great for MS if this takes off - once again they're in the driver's seat and free to call the shots as they see them. And it might help dig them out of their biggest hole - security flaws in Windows.
Downside? Now you can be a lazy programmer writing sloppy code "because .NET will catch your errors at runtime, won't it"?
Now Borland has put Delphi up for sale too - can't compete!
Hooray, we can all look forward to some nice fat proggies taking their own sweet time to load and run in the very near future. Better start saving up for another 3 GB of RAM, guys.

It'll not load and run as quickly due to intermediate bytecode having to be translated to machine code on the fly, and it'll take up more memory due to the overhead caused by the supervising structure.
Any speed gains will only hold so long as the app remains loaded in memory. Reload, and you start from square one again, AFAIK.
The rationale for the .NET framework seems to be that since the just-in-time engine is 'aware' of its runtime environment, it can take steps to thwart potential problems such as memory leaks and security loopholes like buffer overruns, bad array bounds, etc.
It also claims to be platform agnostic and lays down the law according to MS for programming standards (classes, types, bla, bla - not a bad thing by any means).
Call me a cynic, but I smell a late response to the Java Development Platform.
When that became hotter than a chili-pepper a few years back, I suspect there were quite a few worried frowns in the MS camp as they watched the development initiative move away from Redmond. And so now we have .NET.
It's great for MS if this takes off - once again they're in the driver's seat and free to call the shots as they see them. And it might help dig them out of their biggest hole - security flaws in Windows.
Downside? Now you can be a lazy programmer writing sloppy code "because .NET will catch your errors at runtime, won't it"?
Now Borland has put Delphi up for sale too - can't compete!
Hooray, we can all look forward to some nice fat proggies taking their own sweet time to load and run in the very near future. Better start saving up for another 3 GB of RAM, guys.
You're absolutely right there, majki. Where does the gorilla sit when it comes into the room? Why, anywhere it damn well wants to, of course!!majkinator ! wrote:Next, in new MS OSes, Win API will be replaced by it's .NET successor called WinFX. No matter you like it or no, it will be there....

- majkinetor !
- Power Member
- Posts: 1580
- Joined: 2006-01-18, 07:56 UTC
- Contact:
No... after first compilation, exe binary is created and no new version is created until source change is detected. This by the theory. Is it like that in practice, I can't say right now since I am in .NET develpement only 2 months or so... with my new job.Reload, and you start from square one again, AFAIK
Also, I don't know why people say such things about .NET and don't complain much about Java. As I am informed, many of you use FireFox. If you don't have problem with it, why do you have with .NET. According to what I know uptoday, if FF was .NET it would be much faster (and even more faster in the future). If anything is to be expected it is that .NET will be obvious choice for Windows platforms (what we all use here, except that guy with the MAC) not Java. Personally, I don't like neither Java neither .NET for now... I choose to live without them most of the time.
Transition, nothing more... it was about time if you ask me... every higher organisation have more overheads, but we have better programming philosophy and better interface model to kernal...Hooray, we can all look forward to some nice fat proggies taking their own sweet time to load and run in the very near future. Better start saving up for another 3 GB of RAM, guys.
I don't know why is this happening. I have the same results on my own computer. Maybe it differes in practice then in theory (like it do in most of cases). I will inform you if I find something about this. I did that dialog in 15 minutes and I used all default compiler options... maybe I missed some switch ...Moreover, after I worked for some time with other applications like MS Word, I tried to start your program again - and it again took about 2-3 seconds to start. Where the speed increasing (that you're talking about) have gone? And what will see the users of slower machines?
frenky thx for the links.. I will check them.
Habemus majkam!