Windows版の4Dは，フォームの表示と印刷に Direct2D テクノロジーを使用していますが，互換性のために残されているGDI/GDI+ レンダリングモードも限定的にサポートされています。
4D 13では，SVGレンダリングエンジンにDirect2D が採用されました。SVG要素の4D-enableD2D属性を指定することで，SVGレンダリングエンジンを切り替えることができます。SVGフィルターは，Direct2D モードでなければ表現されません。
4D 13では，テキストを除くグラフィック処理にDirect2D が採用されました。さらに，Windows XP/VistaのレンダリングをWindows 7でデバッグするためのデータベースパラメーター69 Direct2D status が用意されました。
4D 16では，リストボックスのテキストレンダリングがDirectWrite に対応しました。4D 15以前に作成されたリストボックスは，互換性のために残されているGDI/GDI+ モードで描画されるのに対し，4D 16以降に作成されたリストボックスは，DirectWrite モードでテキストが描画されます。強制的に切り替わらないのは，DirectWrite とGDI/GDI+ ではテキストのレンダリング処理が違っているためです。リストボックスのテキストレンダリングモードは，データベースパラメーター107 （ドキュメント非掲載）で切り替えることができます。
4D 16では，印刷にもDirectWrite が採用されています。また，旧式プリントレイヤーを使用しなければならない特殊な状況のためにLegacy printing layer option が用意されました。
4D 20では，アプリケーション全体のテキストレンダリングがDirectWrite に対応し，高解像度ディスプレイでテキストがシャープに描画されるようになりました。4D 19以前に作成されたプロジェクトは，互換性のために残されているGDI/GDI+ モードが使用されますが，データベース設定の「互換性」ページでDirectWrite を有効化することができます。設定はSettings フォルダー内のsettings.4DSettings ファイルに書き込まれます。
DirectWriteを使用したWindows上のフォームにおける新しいテキストレンダリング
Direct2D のレンダリングは，グラフィックスカードが対応していれば，ハードウェアアクセラレーションが適用されるため，GDI/GDI+ よりもパフォーマンスが優れています。アンチエイリアス処理や，ガウシアンぼかしなどのSVGのフィルターなどにも対応しています。
リモートデスクトップ環境での描画速度も大幅に改善されます。Windows 7以降のRDPプロトコルはDirect2Dをサポートしているため，従来のようにローカルにビットマップをレンダリングして各端末に送信するのではなく，必要に応じてプリミティブの描画命令を送信し，各端末に描画させることができるためです。
4D Write Pro を使用するためにはDirectWrite モードを有効にしなければなりません。歴史的な経緯により，GDI/GDI+ モードにフォールバックする仕組みがありますが，正式にサポートされているわけではない点に留意する必要があります。
Direct2D のレンダリングは，過去バージョンのGDI/GDI+ とまったく同じではないため，フォームオブジェクトのサイズや，テキストのフォント名などを調整する必要があるかもしれません。互換性を重視したいデベロッパーのためにGDI/GDI+ レンダリングモードも残されていますが，高解像度ディスプレイに対応し，最高品質の印刷と描画を実現できるのはDirect2D レンダリングモードです。
計算属性のFunction getおよびFunction orderBy関数を作成した場合，entitySelection.orderBy("computedAttribute")のような単純なORDA並び替えであればFunction orderByがコールされますが，entitySelection.orderBy("relatedEntities.computedAttribute")のようにリレーション属性が関係するORDA並び替えはシーケンシャル処理なのでFunction orderByではなくFunction getがコールされます。これは仕様です。ただし，パスの代わりに計算属性を使用すれば，その属性のFunction orderByでリレーション計算属性のインデックス並び替えを実装することができます。
なお，リレーション属性のqueryではFunction queryがコールされます（ACI0104799）。
クラシック言語のQUERY BY FORMULAに相当するクエリをORDAで実行する場合，.query()のプレースホルダーとFormulaオブジェクトを使ってフォーミュラ引数を条件に使用したり，eval()ステートメントを使ってテキストでフォーミュラを記述したりすることができます。あるいは，検索条件そのものをフォーミュラで渡すこともできます。
ドキュメントに明記されているように，クエリ条件のフォーミュラはサーバー側で評価されます。
4D Server: クライアント/サーバーにおいては，フォーミュラはサーバー上で実行されます。このコンテキストにおいては，
querySettings.argsオブジェクトのみがフォーミュラに送信されます。
4D 20以降，サーバー側のデータモデルクラス関数がコンパイルモードでは常にプリエンプティブプロセスで実行されるようになりました。
クライアント/サーバーで動作するように設計されているプロジェクトでは、データモデルクラス関数のコードがスレッドセーフであることを確認してください。 スレッドセーフでないコードが呼び出された場合，実行時にエラーが発生します （シングルユーザーアプリケーションではコオペラティブ実行がサポートされているため，コンパイル時にはエラーが発生しません）。
4D 19では，シングルユーザーアプリケーションと同じように，呼び出し元のプロセスによってプリエンプティブまたはコオペラティブプロセスで実行されるという仕様でした。
.query()をクライアント側のプロセスがコオペラティブモードで実行されている場合，eval()やFormulaはそちらのメソッドに記述することになるため，コンパイル時にはスレッドセーフのチェックをすり抜けてしまい，サーバー側のプリエンプティブプロセスで当該メソッドを実行しようとした段階でランタイムエラーが返されることになります。クエリにフォーミュラを含める場合，そのフォーミュラがスレッドセーフであることをしっかり確認してください。
.query()の条件にフォーミュラを埋め込むよりも，クラスを拡張してメンバー関数を実装したほうがORDAらしいコーディングであるといえます。個別のメンバー関数に「プリエンプティブプロセスを使用」という属性はありませんが，スレッドアンセーフなコードはシンボルファイルまたはCompile projectのステータスオブジェクトで確認することができます。クラスを拡張してメンバー関数でサーバー側の処理を記述する場合，クラシック言語や既存のプロジェクトメソッドを混在させたりせず，プリエンプティブモードを前提にORDAでコーディングすることを心掛けると良いでしょう。
4D 20ではC_POINTER($test; 0)（第２引数が間違っている）のようなコードがランタイムエラーを返します。4D 19ではエラーが返されません。なお，どのバージョンでもコンパイル時にコードがシンタックスエラーとして検出されることはありません。宣言レベルでこのようなミスをキャッチするためには，C_@コマンドではなく，varシンタックスを使用することが勧められています。
Outlook アプリのプレビュー表示から4Dの入力エリアに添付ファイルを直接ドラッグ＆ドロップすることはできません。Pasteboard data size("com.4d.private.file.url")が-102を返すことからわかるように，ファイルがドロップされているわけではないからです。
コードライブチェッカーは，タイプ入力中（コピー＆ペーストを含む）にオブジェクト記法の整合性をチェックする新しい仕組みです。var宣言・property宣言・#DECLARE構文およびメンバー関数のプロトタイプ・コンポーネントの名前空間といった新しいシンタックスを十分に活用していれば，従来のシンタックスチェックでは検出できない，論理的な不整合がエラーまたは警告としてコーディング中に表示され，ミスを未然に防ぐことができます。
コンパイルまたはシンタックスチェックを実行すると，ライブチェッカーの警告は一旦クリアされます。enterキーでトークナイズを実行するか，メソッドの編集を再開すると，ライブチェッカーが発動し，警告が再表示されます。これは仕様です。
GET MEMORY STATISTICSとCache infoから返される情報，およびランタイムエラーに表示されている「使用中仮想メモリ」の値は，Windowsの場合，MEMORYSTATUSEX構造体のullTotalVirtualフィールドからullAvailVirtualを差し引いた値です。「仮想アドレス空間のユーザーモード部分で予約あるいはコミットされている仮想メモリの量」なので，厳密な意味で「使用中」ではないかもしれません（PowerShellのProcess.VirtualMemorySize64では，この値がAllocated memory と表現されています）。