>>Integration of things like LDAP access to operating system features via ADSI, the use of XML and ADO as data interchange mechanisms for the OS, and a more database-oriented view of the operating environment all seem to point to a data-centric paradigm not just for the application, but for the system as a whole. As the OS relies more and more on native database tools, I firmly believe that there will be a database orientation to the base file system for the platform. If this happens, everything will have a strong native file system available to it, and the behavior of that file system will become uniform for all aspects and language platforms. We have a lot to learn from the AS400's operating system design.
>
>Actually, the idea is not that new. Remember the RMS in RSX (i.e. record management system on PDP-11) or in VMS? No compiler needed to have its own file/record/indexing system, they all used the OS's services for that. Even when we ported the stuff from PDP to VAX, we just recompiled - the system calls were ported, the RMS was all new (character fields were right-trimmed now, and indexes were compact, but we didn't even notice until I hexdumped them once). We may expect something like that available today. It may be called SQL-something, but that's something we should foresee.
>

Lots of places - the intrusive takeover of MVS's filesystems by VSAM, PICK and plenty of others. I was thinking in terms of the AS400's object database that manages access and permissions, which is manipulable with the sme tools as are used to deelop apps.

>>IOW, I want to abandon much of the xBASE-y/ISAM-ish things that I feel burden the basic VFP engine in favor of a move towards a language which encourages moving away from our procedural roots.
>
>As someone mentioned once, it all fits into the first 600K of the runtime, and is not much. But then the syntax is overburdened with stuff, and the inconsistencies appear here and there.

It's certainly possible that legacy support only ties up 600K, but I'd be a bit skeptical (the base VFP code looks to be ~4.5MB whenI first start it under NT - we still carry much of the really horrendous stuff for emulating the foundation read and the FPW UI legacy. Even if we just had a switch that could disable the legacy support, to shrink the footprint and optimize pcode evaluationat the request of the developer would be a step in the right direction. If people want to write xBASE code, fine; that's not what I want to do, and I'd gladly forego the 17 extra ways to do something to get closer to what I want.