Tag - CrossPlatform

Entries feed - Comments feed

2012-08-10

Microsoft states: OleDB out - enjoy ODBC!

For our native connection to any DB, we developed a set of classes and several units.

We implemented at first OleDB, then native Oracle direct access and SQlite3 static engine.

Now, Microsoft is officially deprecating OleDB, and urge all developers to switch to the open and cross-platform ODBC API for native connection.

Continue reading

2012-04-19

Smart: mORMot, from Delphi to JavaScript

Did you hear from the great Smart project?

It is an IDE and some source runtime able to develop and compile an Object-Pascal project into a HTML 5 / CSS 3 / JavaScript embedded application.
It does target AJAX Mobile application creation (i.e. Android and iPhone/iPad apps running Web-Kit).
You'll get an unique .html file containing the whole client-side application: it won't need any server side implementation. Using a third-party tool like PhoneGap, you'd be able to supply your customers with true native applications, running without any network, and accessing the full power of any modern Smart Phone.

Smart is a great candidate for implementing rich client-side AJAX applications, to work with our client-server mORMot framework.

In order to interface Smart code with mORMot, we started implementing some low-level code to work with our RESTful authentication scheme.

So we'll need to implement some Smart dedicated Open Source code implementing crc32 and SHA-256 hashing.

Continue reading

2011-11-08

Currency is your friend

The currency type is the standard Delphi type to be used when storing and handling monetary values. It will avoid any rounding problems, with 4 decimals precision. It is able to safely store numbers in the range -922337203685477.5808 .. 922337203685477.5807. Should be enough for your pocket change.

As stated by the official Delphi documentation:

Currency is a fixed-point data type that minimizes rounding errors in monetary calculations. On the Win32 platform, it is stored as a scaled 64-bit integer with the four least significant digits implicitly representing decimal places. When mixed with other real types in assignments and expressions, Currency values are automatically divided or multiplied by 10000.

In fact, this type matches the corresponding OLE and .Net implementation of currency, and the one used by most database providers (when it comes to money, a dedicated type is worth the cost in a "rich man's world"). It is still implemented the same in the Win64 platform (since XE 2). The Int64 binary representation of the currency type (i.e. value*10000 as accessible via PInt64(aCurrencyValue)^) is a safe and fast implementation pattern.

In our framework, we tried to avoid any unnecessary conversion to float values when dealing with currency values. Some dedicated functions have been implemented for fast and secure access to currency published properties via RTTI, especially when converting values to or from JSON text. Using the Int64 binary representation can be not only faster, but also safer: you will avoid any rounding problem which may be introduced by the conversion to a float type. Rounding issues are a nightmare to track - it sounds safe to have a framework handling natively a currency type from the ground up.

Continue reading

2011-09-25

Some thoughts about OSX integration in XE2

You know all that one of the most exciting features of Delphi XE2 is the MaxOSX Cross-Platform feature.
You've got the UI part, that is FireMonkey, but underneath, you did have some RTL modifications in order to let our Windows-centric solutions be OSX ready.

The first main step was to make our code speak with the "Objective-C" way of coding.

Objective-C is the primary language used for Apple's Cocoa API, and it was originally the main language on NeXT's NeXTSTEP OS. It's some object-oriented C variant, but something other than C++ or Java. In fact, Objective-C sounds more like a SmallTalk variance of C than another  C++/Java/C# flavor. For instance, the Objective-C model of object-oriented programming is based on message passing to object instances: this is just another way of doing it. It has some advantages, and disadvantages (I don't want to troll here) - but it is definitively nice. And the memory model is just something else, more close to our reference-counting way (as in Delphi interface implementation) than a garbage collector.

Continue reading

2011-08-11

FireMonkey and DXScene

For those how are interested in FireMonkey, I made some screenshots of some DXScene sample app.

It may give you some good starting point about the features of the upcoming Delphi XE2 user interface components.

Continue reading

2011-08-08

Our mORMot won't hibernate this winter, thanks to FireMonkey

Everybody is buzzing about FireMonkey...

Our little mORMot will like FireMonkey!
Here is why...

Continue reading

2010-08-14

FPC and Delphi: toward a "fratricidal war"?

Speaking about [upcoming] 64 bit Delphi compiler, I did forecast they will surely release their compiler 5 years later than FPC's... hoping they will follow the FPC way, just as Intel did about 64 bits instructions, against AMD.

What I was referring to is that AMD was the first to publish a 64 bit x86 CPU, with a new instruction set. Intel released somewhat later their own 64 bit x86 CPU, following the same instruction set.
There are some variants between AMD and Intel CPU, some dedicated instructions or implementations.
But most instruction set is perfectly compatible.

And I suspect the more it gets, the less compatible FPC and Delphi will be.

The main difference between Delphi and FPC is that the first is a business company project (Embarcadero), the second an Open Source solution. They are not two billions dollars companies fighting each other, with some state-level institutions watching about any unfair competition or monopoly... FPC compiler is technically a great and robust project, but EMB follows business rules. I don't think anyone will play "Anti-monopoly" in favor of FPC.

Continue reading

2010-08-10

Writing Delphi code for 64 bits compiler

There will be an upcoming 64 bits Delphi compiler. Embarcadero promised it.

Florian (the architect of FPC) showed a first "Hello world" program for Win64 in March 2006.
This was remarkable since GCC and the binutils don't even support this target at this time.
In fact, FPC used its Internal linker on Win32 and Win64 platforms, just like Delphi does.

Here are some points on how you could make your code ready to compile under FPC 64 bits, therefore (I hope) under future Delphi 64 bits compiler.

Continue reading

2010-08-06

Save object, stop class hegemony!

In a recent thread in the Embarcadero Discussion Forums, Vedran Vuk posted some questions about object keyword.
His purpose was to use object instead of class to improve speed and memory consumption: 

I do use classes. I just want to use objects on smaller classes that don't really need initialization or RTTI. Plus, I can directly operate on it like a record with no need for constructors and it can be sealed and has inheritance. Every byte matters in this case.

Rudy posted on the EMB forum that

The "object" type is deprecated. As was said, it mainly exists for compatibility with old Turbo Pascal. That is why it is not documented very well. It's use is not promoted.

I have the same requirement sometimes, for example for our framework or for low-level units.
I do like such plain-old object type, and don't want to see this object feature marked as deprecated in future EMB versions.

Continue reading

2010-07-27

Hyphenation in Delphi

We made some years ago a Delphi unit for hyphenation of text.

Such an unit, together with our SynPdf library for example, could be useful in your application. So we released the source!

Continue reading

2010-03-28

Mac OS X Stack Alignment, asm and trolls

In a very interesting commentPhiS spoke about the Mac OS X Stack Alignment problem, and the way asm code should be written for the future Cross Platform Delphi compiler. Here are some (hope without any Troll hidden) reflections I went through.

Continue reading

page 3 of 3 -