Thanks David.

By the way, I didn't take your comments as being aimed at VFP at all. I was trying to check my understandings of VFP in the context of your comments about .NET.

For what it's worth, I expect to be deep into .NET some day. I'm letting you pioneers do all the hard work. Once you've (all) cleared the land and built the infrastructure I'll come on in and buy me a lot.


>My comments were not directed against VFP on any of these points. I was thinking more generally of all reference counting COM pre-.NET apps. The foxpro runtime does offer some safeguards that are commendable. Self modifying code, as you probably know, was mostly a hack from the assembly language days.
>
>Remember that patch program that fixed the 333 MHz bug in Fox 2.6? Can't be done as far as I know in .NET because as soon as you try to tamper with an assembly it would break the strong name signing and the CLR would refuse to load it.
>
>Garbage collection is better in the CLR because it will detect circular references. I have spent weeks tracking down circular reference problems in complex OOP systems in VFP. That type of problem should be a thing of the past in .NET (least thats the theory, haven't worked on systems as complex yet). Of course garbage collection has its own issues beause resources may not be released in a timely manner, but thats another story. Two steps forward, one step back.
>
>>David,
>>
>>I'm just trying to get some clearer understandings here...
>>
>>1) pointers or self-modifying code... I am not aware that VFP has support for pointers and I am keenly interested in anything you can point me to to confirm that VFP's code can, indeed, be self-modifying.
>>
>>2) garbage collection... are you saying that VFP doesn't do any or are you saying that it is done better in CLR?
>>
>>thanks in advance
>>
>>
>>>Many things.
>>>.NET code runs in a managed enviroment, the CLR which is like a virtual machine. It doesn't allow pointers or self modifying code. Garbage collection is controlled by the CLR that cleans up circular references. Code access security assures that the identity of the calling routine is really who it claims to be. Permissions can be demanded of the calling code and managed with a security policy.
>>>There are many, many advantages to running in a managed environment.
>>>
>>>
>>>>What would make a .NET Framework application be more reliable than a VFP application? And, what would make it more secure? At first, this is based on a set of minimum requirements. Without those requirements, also, how could such an affirmation be made?