Component |
Description |
XSharp.Core |
This is the main runtime DLL. It is written in the X# Core dialect.
- Written in X# Core dialect
- Uses only standard .Net data types
- Has all the functions and types that do not require XBase types
- Includes (managed) Low level file I/O (FOpen, FRead, FWrite)
- Declares common interfaces, such as IDate, IFloat, ICodeBlock, IMacroCompiler, used by other X# components
- Has the Runtime 'State' and Workarea information
- Includes typed RDD functions. NO usual support.
- Has only "safe" types and code. So in stead of PTR for file pointers IntPtr is used.
- It has the 'Nation' support such as collation tables, messages etc
|
XSharp.VO |
This is the runtime DLL that contains the support for specific things for the VO/Vulcan dialect
- Written in X# VO dialect
- Declares the XBase types
- USUAL, DATE, FLOAT, SYMBOL
- ARRAY, CODEBLOCK, PSZ
- And more
- Has the functions that use these types (Str(), Ntrim etc)
- Adds USUAL support to the RDD system (DB.. Functions, some VODB.. Functions)
- Has the Console API (? , ?? )
- Has the support for MEMVARs (PUBLIC, PRIVATE)
- Has the support code for using the Macro Compiler (MCompile, MExec etc)
- Has the MemAlloc() en MemCopy() code
- Is "Unsafe"
|
XSharp.RDD |
THis DLL contains all of the XSharp RDDs
- Depends on Xsharp.Core.DLL
- Written in X#, Core dialect.
- Will include support for
- Advantage
- DBF DBT NTX
- DBF FPT CDX
- DBFBLOB, SDF and DELIM
- And in the future possibly ?
- DBF , DBT , MDX
- DBF SMT NSX
- What do you need ?
|
XSharp.Macrocompiler |
There will be 2 macro compilers. One "Full" macro compiler and one "Fast" macro compiler. The "Full" macro compiler will be based on the Roslyn code, and is a wrapper around our scripting engine The "Fast" macro compiler is hand written and will support "just" the VO compatible macros. Both macro compilers are written in C#. |
VO Compatible Class Libraries |
The VO Class libraries that come with Visual Objects are copyright of Computer Associates. We therefore can't simply recompile them and include them with our product. Fortunately the source code to these libraries is included with every installation of VO since VO 2.5. Our solution for this is:
- We will create a tool that will take the VO source code for GUI, System, RDD, SQL and Win32API from your VO Installation.
This will only work if you have a valid license of VO.
- The tool will create a "personalized" version of these libraries for .NET and will produce VS and XIDE solutions.
The username and serial number from your VO installation will be included in the assembly information for the generated assemblies.
- The tool will use MSBuild to produce binaries linked against the X# runtime.
- You can open this source later if you want to make manual changes or include your changes to the SDK.
- You can then use these personalized versions with the apps that you convert from VO
|
Unicode and AnyCPU Support DLLs |
The VO Compatible class libraries are based on the X86 and Ansi API calls inside windows. For some of these assemblies there is no problem using them in a Unicode and AnyCPU environment, such as:
- System Classes
- RDD Classes
Other assemblies will not work without significant changes in a Unicode and AnyCPU mode. We plan to come with newly written versions of these assemblies, that will also no longer use the Win32APILibrary from VO.
- GUI Classes, which will be built on top of Windows Forms, but from the "outside" will still function like the VO GUI classes, so you can use your existing code with minimal changes.
- SQL Classes, which will be built on top of Ado.NET. The outside of these classes will look the the SQL classes from VO, but internally it will use Ado.NET. The default behaviour of these classes will be to (still) use the ODBC provider for Ado.NET. However you will be able to specify in your code that the class library needs to use another .Net dataprovider, such as the providers for SQL Server, Oracle, MySql or others.
|
This is great news. Thanks for heads up.
I will revised my development schedule and release timeline to sync it with yours'.
Thanks,
Rene
[quote name="Stavros Spanos"]Great!! I think this should be posted to comp.lang... also. A lot of people still keep an eye on it.[/quote]
Well, what is stopping you.
I considered posting a message, but decided not to do because others might see it as spamming / advertisements
Robert