fbpx

With this article I want to start a series of articles with tips that can help improve the performance of your apps when they are moved from Visual Objects and/or Vulcan to X#.

The first tip is to use the IS comparison in stead of IsInstanceOf()

Try the following code in a VO Console application:

FUNCTION start AS VOID 
LOCAL oErr AS OBJECT
LOCAL nI AS LONG
LOCAL f AS FLOAT
oErr := Error{}
f := Seconds()
nI := 0
FOR VAR nX := 1 TO 10_000_000
IF IsInstanceOf(oErr, #Error)
nI++
ENDIF
NEXT
? Seconds() - f, nI
f := Seconds()
FOR VAR nX := 1 TO 10_000_000
IF oErr IS Error
nI++
ENDIF
NEXT
? Seconds() - f, nI
WAIT

We sometimes get a question about the differences between the VO and Vulcan dialect.

In the table below we have tried to list these differences

DescriptionVOVulcan
Keyword abbreviations Supported for all 'old' keywords for 4 letters or more. See table on https://www.xsharp.info/help/x-keywords.html. All the keywords in the VO column may be abbreviated. Only supported for
PROCEDURE (PROC)
FUNCTION (FUNC)
LONGINT (LONG)
SHORTINT (SHORT)
String literals String literals can be defined with single quotes and double quotes:
"This is a string"
'This is a string with an embedded double quote "'
String literals can only be defined with double quotes
Char literals Must use single quotes prefixed with 'c', e.g. c'A' Single quotes, the 'c' prefix is optional, e.g. 'A'  and also c'A'
PSZ indexer PSZ indexing is 1 based PSZ indexing is 0 based (this is actually a bug in Vulcan that we are emulating)
MemVars (PUBLIC, PRIVATE) Yes (in a future release) No
Single line comments Uses both // and && Only // is supported.
&& is a synonym for .AND.
Compiler macros defines __DIALECT_VO__ and __VO__ defines __DIALECT_VULCAN__ and __VULCAN__

Something else that needs to be mentioned: if you switch from the Vulcan runtime to the X# runtime, please remember to remove the #include statements for the Vulcan header files, such as VOWIn32ApiLibrary.vh)

The values in these header files are now stored as defines (constants) in the VO SDK assemblies, such as VOWin32APILibrary.dll and also in the runtime assemblies (for values from VOSystemLibrary.vh).
Removing the header files will most likely improve the compilation speed.

In our attempt to make X# as compatible as possible we are supporting almost all the constructs of the VO language. One of the language constructs that gives some problems is the _CAST operation.

Take the following code:

FUNCTION start
LOCAL uValue AS USUAL
LOCAL siValue AS SHORT
uValue := 100
siValue := SHORT(_CAST, uValue)
? uValue
? siValue
WAIT
RETURN NIL

Which result is printer for siValue and uValue ?

Most of you will answer 100, and that is correct.

What if we change the example to:

FUNCTION start
LOCAL uValue AS USUAL
LOCAL siValue AS SHORT
uValue := MyFunction()
siValue := SHORT(_CAST, uValue)
 ? uValue
? siValue
WAIT
RETURN NIL

FUNCTION MyFunction
RETURN 1 - PI

What will the answer be ? (And yes, PI is a predefined constant in VO and X# with the value of 3.14159265358979323846). And please, don't cheat, don't run the example in VO. Just solve this in your head.

When we designed the X# compile and X# Runtime we had a few focus points in mind:

  • The language and runtime should be VO compatible whenever possible. We know that the Vulcan devteam made some decisions not to support certain features from VO, but we decided that we would like to be as compatible as technically possible.
  • We want our runtime to be fully Unicode and AnyCPU. It should run on any platform and also both in x86 and x64 mode.  That has caused some challenges because VO is Ansi (and not Unicode) and also X86. In VO you can cast a LONG to a PTR. That will not work in X64 mode because a LONG is 32 bits and a PTR 64 bits
  • We want the code to compile in "Safe" mode. No unsafe code when not strictly needed. The biggest problem / challenge here is the PTR type. With a PTR you can access memory directly and read/write from memory, even if you don't "own" that memory. However the same PTR type is also used as "unique identifier" for example in the low level file i/o and in the GUI classes for Window and Control handles. These PTR values are never used to read/write memory but are like object references. We have decided to use the .Net IntPtr type for this kind of handles. Of course the compiler can transparently convert between PTR and IntPtr.
  • We want to prove that the X# language is a first class .Net development language. That is why we decided to write the X# runtime in X#. By doing that we also create a large codebase to test the compiler. So that is a win - win situation.
  • We want the runtime to be thread safe. Each thread has its own "global" state and its own list of open workareas. When a new thread is started it will inherit the state of the main thread but will not inherit the workareas from the main thread
  • At this moment the X# Runtime is compiled against .Net Framework 4.6.

In the previous article I have described how the xBase world evolved from DOS/Dbase and DOS/Clipper to Windows/Visual Objects and how that affected the character sets. OEM character sets for DOS/Clipper and Ansi Character sets for Windows/VO.

In this article I would like to discuss the relevance of all of this in relation to X#.

Introduction

To start: X# is a .Net development language as you all know and .Net is a Unicode environment. Each character in a Unicode environment is represented by one (or sometimes more) 16 bit numbers. The Unicode character set allows to encode all known characters, so your program can display any combination of West European, East European, Asian, Arabic etc. characters. At least when you choose the right font. Some fonts only support a subset of the Unicode characters, for example only Latin characters and other fonts only Chinese, Korean or Japanese.
The Unicode character set also has characters that represent the line draw characters that we know from the DOS world, and also various symbols and emoticons have a place in the Unicode character set.

At the XBase Future conference in Cologne we have presented the development roadmap. We would like to share that with you here as well.
For us 2018 is all about finishing the X# runtime.
This runtime consists of the following components:

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.

 

 

Introduction

We have been quite busy creating the X# runtime. And when we did that we stumbled on the problem of bytes, characters, codepages, Ansi and Unicode. X# has to deal with all of that and that can become quite complicated. That is why we decided to write a blob post about this. In this post we look back to explain the problems from the past and how the solutions to these problems are still relevant for us in a Unicode XBase environment such as X#.

Bytes and Characters in DOS

When IBM introduced Dos in the 80’s the computing world was much less complex than it is right now. Computers were rarely connected with a network and certainly not with computers outside the same office building or even outside the same city or country. Nowadays all our computers are connected through the internet and that brings new challenges for handling multiple languages with different character sets.

The origin of the XBase language was in CP/M (even before DOS) and the XBase runtimes and fileformats have evolved over time taking into account these changes.
Before IBM sold computers they were big in the typewriter industry. So they were well aware that there are different languages in the world with different character sets. Their IBM typewriters came in different versions with a different keyboard layout and different “ball” with characters. There were different balls with different character sets and different balls with fonts (Courier and Prestige were the most used, with 10 and 12 characters per inch).
DOS used a single byte (8 bits) to represent characters. So there was a limited number of characters available.  The number was certainly not big enough to represent all characters used by languages for which IBM was developing computers.
That is why IBM decided to group characters in so called Code Pages. The most common codepage used in the US and many other countries in the world was code page 437.

dos437

Code page 437

This codepage contains all non-accented Latin characters as well as several characters with accents, several (but not all) Greek characters, the inverted exclamation mark and question mark used in Spanish and quite some line draw characters, used to draw different boxes on the 25 x 80 DOS displays.

In the last build of X# we have introduced a small problem in some of our project templates (more about that later) and when trying to instruct one of our customers how to fix that I realized that it might be a good idea to explain our project file format a little bit.

But first let’s look back at the past.

Some of us have started development in the DOS days and may remember how the build process worked in the DOS/Clipper time:
You had a folder full of source code, an RMake file with instructions on which files needed to be compiled and what the compiler commandline needed to be and a Link file with instructions on how to link the object files produced by the compiler with the standard Clipper libraries and sometimes also with 3rd party libraries.
The Rmake file contained rules that described the dependencies: The Exe file depended on a list of OBJ files, which in their turn depended on PRG and CH files. When one of the PRG or CH files was newer than the OBJ file (or the OBJ file was missing) then the compiler would be called and a new OBJ file was created. After that the linker was called because the OBJ file was newer than the EXE file.
Btw (x)Harbour uses a similar way to compile.