In our ongoing effort to improve the building of 4D applications, we’ve added a few functionalities to 4D v19R5 that you’ll certainly find useful.
The first one is the ability to remove some of the biggest 4D modules from your applications: CEF, Mecab, PHP, Spell Checker, and 4D Updater. If you don’t need some of these modules, you’ll be able to significantly reduce the size of your applications.
We also changed the final directory when you build a compiled structure, in order to accommodate those using multiple compiled versions of the same structure.
As for our Japanese customers, we have merged the Japanese version of 4D and the international one on MacOS.
Let’s delve into the details.
Year after year, feature after feature, the diagnostic log has grown into a massive file on busy servers. With 4D v19R5, we included a new database parameter allowing you to choose the log level of the diagnostic log file. It will help you control the diagnostic log size by logging only what you really need.
It’s sometimes helpful to monitor 4D licenses on your server. That’s why with 4D v19 R4, we decided to provide you with a new command giving all the information about your license usage: Get License Usage. Let me introduce you to this new tool.
At 4D, we take customer requests very seriously!
In previous meetings, customers showed great interest in supporting high-resolution displays, such as 4K displays, in Windows. Your wish has been fulfilled as we have added support for High DPI in 4D.
DirectWrite is the modern text rendering API on Windows. It improves text readability thanks to its subpixel quality, and is fully compatible with the most recent technologies. As such, it is a stepping stone to many improvements. Amongst them, the management of high-resolution screens (4K screens) we’re currently working on, and that many of you dearly expect. 4D list boxes moved to DirectWrite in v16 and we decided to make the switch for our text rendering inside forms in v19R3.
For 4D v19, we started a long-term refinement of our logs. Our first effort was to improve their format to give you better and clearer information. As for 4D v19 R3, we added 2 new functionalities: the ability to instantly pause logging and a way for support teams to easily help their customers configure their logs through a configuration file.
The release of Silicon Macs had a great impact on the way 4D compiles applications. Before v19, 4D was compiling only for Intel architecture, using the same code on Mac and Windows. But Silicon Macs use a new architecture, and as such 4D needs to compile specifically for Silicon. It affects cross-platform client/server application building.
As long as you build your server on Mac, it’s not much of an issue, as you can compile for both Intel and Silicon platforms. But on Windows, it’s not possible to compile for Silicon Macs. Our current recommendation is to compile the project on Mac for both architectures, and then copy it on a Windows machine before building the server. Unfortunately, for big projects with a lot of data, the copy can take some time.
On Mac, application signature has become a standard, and since Big Sur, you can’t even run unsigned applications. In the past, we published a workaround to build client-server applications running on a Windows server and accepting connections from Mac clients. With the release of 4D v19, we have updated the application building in 4D to handle this case. Here is how you can build a single platform or a cross-platform application in v19.
We recently reviewed the formats of our logs to increase their readability and their compliance with automated analysis. We made these improvements in response to real-life situations we experienced, directly addressing issues that were hindering our ability to use 4D logs. In this blog post, we’ll explain in detail what changes we made so you can adjust your log analyzing tools accordingly.
We already introduced you to our new Silicon compiler in a previous blog post. This new compiler will be used to build Silicon native applications and will be available only in project mode.
Intel native applications (on Windows and Mac) will continue to use the classic compiler.
Let’s dig deeper and see exactly how it works.