Board index » delphi » Re: 100% pure Win32 IDE

2006-09-05 02:38:53 PM
delphi205
Atmapuri writes:
produce memory leaks and bugs that are hard to trace and debug in
Win32, let alone in .NET.
OTOH, it is not me you need to convince <g>
--
Dave Nottage [TeamB]
 

Eric Grange writes:
Applications may gobble up memory that may r may not be released by
the garbage collector until the system *needs* that memory.
Because of this, the start of a new application or module can be much
slower than before because memory has to be freed first. When it's
running, however, all should be OK. But the system as a whole feels
slower IMHO.
The same theorem applies to "Windows Mobile".
I have a smartphone/PDA with this operating system, and applications
remain in memory even when you close them. This makes subsequent
starts faster, but occasionally a new program (such as the "camera"
app) refuses to work because of lack of memory and I have to use the
task manager to kill every running task. As a whole, I dislike this way
of doing things. I find myself killing tasks several times daily.
Under Win32, there's always the occasional ill-behaved application that
consumes memory before releasing it. But closing that application
always instantly fixes the problem. Even if you don't close it, the
operating
system will swap out the least recently used memory pages to make
memory available if you need it.
Under .NET, you can rely on it that memory will always be short and the
CPU load will show bursts of activity when the garbage collector kicks in
(this will also reduce the running time of battery-operated notebooks
BTW). I think it is a step backwards.
--
Arthur Hoornweg
(In order to reply per e-mail, please just remove the ".net"
from my e-mail address. Leave the rest of the address intact
including the "antispam" part. I had to take this measure to
counteract unsollicited mail.)
 

viable it would also mean that there would be no dotnet development support.
I'm glad you're not the new Delphi project manager :-)
--
Pete
Blessed are the geek, for they shall public class GeekEarth : Earth {}
====
Audio compression components, DIB graphics controls, ECO extensions,
FastStrings
www.droopyeyes.com
====
 

Brian Twinings writes:
I fully agree, I see it the following way:
.net is a strategical move by Microsoft to
1) tighten the ties of windows "developers,developers,developers" by
giving them difficult to resist candy
2) keep control of the apps that run on top of it
3) loosen the grips of Intel on Microsoft, after all, the JIT interpiler
is like a CPU, having your own CPU makes you less dependent
4) insure that the competition looses time aiming at a moving target
I use macs, windows and linux, I would love to be able to develop with
Delphi for all of these platforms. Sure, Microsoft *might* be working on
a .net interpiler for the mac, but when will it be available, and how
will it work ?
Claude
 

This would surely speed up new developments. Good suggestion!
Rick
 

memory: the .Net application(s) may not have CPU time (idle or not), and
thus won't be able to free anything, which will result in memory
swapping (happens all the time you have a .Net app with lots of
allocated RAM AFAICT).
Then comes the worse bit: having been noticed it should be freeing up
memory, the .Net app will then proceed to GC... on the swapped out
memory... further straining the system. Add to that the GC is just not
efficient at all when GC'ing swapped out memory, and you have the
explanation of why .Net apps are perceived (with good reason) as memory
hogs.
The trouble can usually start before you even run into swapping, simply
because by using more memory, you leave less room to the file cache (the
thing that uses the "unused" memory). Should an application with lots of
file access kick into high gear (a database, a compiler...) it will have
to re-read from the HD what could have been in cache had the .Net
application been more parsimonious.
Eric
 

"Claude Rieth" <XXXX@XXXXX.COM>writes
Mono, the .NET platform which targets Linux, Solaris, Mac OS X, Windows and
Unix.
www.mono-project.com/Main_Page
I'm not sure if the Delphi compiler works on Mono yet, but if not, the next
best thing is Chrome.
 

 

the plot.
There are many layers of battle, some are technical, many are political
(IMO, this is the case here).
Eric
 

Last time I checked, they still had trouble displaying forms with
buttons and edit boxes...
Eric
 

But the together code allows the refactoring to work - you
can't have one without the other. So they would have to
write the refactoring code from scratch. I don't think that
you want to wait that long.
Rgds Pete
"Thomas Miller" <XXXX@XXXXX.COM>writes

Brian Twinings writes:
here's a howto remove .net from BDS 2005, dont know if it works in 2006.
delphi.about.com/od/delphifornet/a/delphi2005win32_3.htm
Regards,
Claude
 

Hi!
needed. In case of Delphi.W32 it could be possible not to
use any .NET modules..., but instead load them dynamicaly
when working on .NET applications...
Regards!
Atmapuri
 

Hi!
The question of .NET or not comes down to just a few subsystems in case
of Delphi.W32. Most notably ErrorInsight... and i wonder if anything else...
So, running the IDE without .NET is totaly feasible. And DevCo would
not be the first to port their .NET application back to unmanaged code.
I hear about it more and more...
I was working a lot on .NET lately, I think its absolutely a great thing
for "developer". But not neccessariliy a great thing for the "customer".
The ability of garbage collected objects is great and I love it and
until i started using the concept I had no idea how much of a burden
that is.
So I believe that .NET has its place..., but not everywhere...
Regards!
Atmapuri
 

tirania.org/blog/archive/2006/May-19.html
--Dag--