- Created: 21 November 2018
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:
LOCAL uValue AS USUAL
LOCAL siValue AS SHORT
uValue := 100
siValue := SHORT(_CAST, uValue)
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:
LOCAL uValue AS USUAL
LOCAL siValue AS SHORT
uValue := MyFunction()
siValue := SHORT(_CAST, uValue)
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.
- Created: 16 November 2018
This year we have another special offer on our subscriptions to celebrate Black Friday.
Buy a FOX subscription this week and enter the coupon code "BLACKFRIDAY2018" and you will get a 35% discount on your purchase.
Please note that this discount code can't be combined with other discount codes.
- Created: 15 November 2018
A quick message to inform you of some of the things that are happening in the X# team.
- We know that many of you (just like us) love footbal (soccer). Wouldn't it be great if you could combine soccer with technology.
It turns out you can. At the university of Twente a team of you students is working on Robot soccer.
We like that idea so much that we have signed up as sponsors: https://roboteamtwente.nl/
- We have received a request from the community to start adding support for the XBase++ dialect to the compiler. We have analyzed the language differences, and it seems that there are very few differences. The biggest change is the way that classes are declared. XBase++ follows the "Class(y)" style of class declaration (Anton van Straatens OOP extension to the Clipper language).
The class declaration syntax for XBase++ is also almost identical as the syntax for (x)Harbour. So we might combine the two.
At this moment we are working on the XBase++ support in the parser and compiler.
After that we will add runtime support for the XBase++ dialect.
This new dialect will most likely not be included in the upcoming releases , but we still would like to inform you.
Our XBase++ customer wants to run his code in a webservice. So no UI. Most likely we will create some kind of poor man's UI that emulates the CRT windows on the console.
If you are interested in XBase++ support and would like to contribute on the UI or specific runtime functions (maybe a library like Sql Express or XBase Tools) please contact us.
- Created: 10 November 2018
We have released X# Bandol Beta 7. This build fixes some issues found in Beta 6, adds the Hybrid classes that were also present in Vulcan (thanks Paul Piko) and some functions that we had overlooked in previous betas.
- Created: 28 October 2018
We are very happy to announce that we have uploaded X# Bandol Beta 6 for our FOX subscribers.
This build adds the RDD support to the runtime including the DBF-DBT-NTX RDD and the advantage RDDs. We have also included DBF-FPT. CDX is not available yet.
We have also included compiled versions of the VO SDK Class libraries that are compiled against the X# runtime.
The complete list of changes can be downloaded from https://www.xsharp.info/itm-downloads/download?path=general%252FReadme%252Fwhatsnew2006.rtf.
- Created: 22 October 2018
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#.
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.
- Created: 10 October 2018
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.
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.
- Created: 05 October 2018
You haven't heard from us in a while, so some of you might be wondering what we are doing.
Well, the answer is that we are working very hard (our wifes say too hard <g>) to finish the X# runtime.
At this moment the status of the runtime is:
- 97 percent of the functions are implemented, tested and working.
- The DBF/DBT RDD is implemented and working
- The Advantage RDD is implemented and working (you can use this for DBF/DBT/NTX, DBF/FPT/CDX, ADT/ADM/ADI and the various SQL variants)
- The NTX RDD is almost completed
- The FPT layer for DBF/FPT/CDX is implemented and working. We have not started with CDX. If you need DBF/FPT/CDX you can use the Advantage RDD in combination with the Advantage local server for now.
- The VO SDK is compiling without errors (which means that also all the undocumented VO stuff has been implemented).
- And everything is AnyCPU and thread safe. Of course when you use the GUI classes from the VO SDK and/or the SQL Classes then you are limited to x86 because these classes are not designed for AnyCPU.
We have also made some improvements in the Visual Studio support
- Opening of very large Solutions now is MUCH faster
- We have fixed some issues that were reported
Finally we have made some changes to the compiler that were needed for some special cases related to compiling the VO SDK (this SDK contains some really ugly code...) and we fixed some issues reported by our customers.
We plan to publish our "work in progress" in a new beta for FOX subscribers end of next week, that means if we can succeed to reach our goal:
Our intention for the next beta is that applications that use the standard VO SDK libraries and no 3rd party components should work with minimal changes.
You may have to change the RDD name, but the rest should work.
If you have already changed your code for Vulcan you should be able to swap the Vulcan runtime and Vulcan SDK libraries for our Runtime and SDK libraries, recompile your code and run.