4th Dimension Learning Basics

If you are coming to 4D (4th Dimension) from FileMaker Pro, Microsoft Access, or a modern low-code tool, the first thing you need is an honest map of the terrain. The original “4th Dimension Learning Basics” page was written as a side-by-side comparison of system requirements between FileMaker Pro 5.0 and 4th Dimension 6.5 — a snapshot from roughly 1999–2000.

That snapshot is still useful, but only if you understand why those requirements differed and what they tell you about how the two products think about the world. This article preserves that original comparison and builds the context around it: what the numbers meant, how the platforms diverged, and how to make practical decisions today when you inherit or maintain a 4D system.

Key Takeaways

• The original FileMaker vs. 4D requirement tables are a historical baseline, not a buying guide — treat the specific RAM and OS figures as period artifacts.
• The single most important architectural difference is that 4D is a programmable relational database development environment, while FileMaker Pro was positioned as an end-user database application.
• 4D’s separation of structure, methods, forms, and data files is what makes it scale from a single-user desktop tool to a client/server and web-published system.
• Networking model, runtime licensing, and compiler availability are the three areas where 4D and FileMaker diverged most sharply — and where migration decisions still hinge today.
• Modern 4D (4D v20 and later) runs on current macOS and Windows, speaks SQL and REST, and integrates with Git — the 6.5-era constraints no longer apply.

The Original Comparison, Preserved

The source material compared two products head to head. Here is that comparison, kept intact because it documents a real moment in the history of desktop databases.

FileMaker Pro 5.0 — Macintosh: Power Macintosh; 16 MB of RAM; Mac OS version 7.6.1 or later; CD-ROM drive and hard drive; and TCP/IP or AppleTalk network connection (required for sharing FileMaker databases over a network). Web publishing requirements included a host computer with continuous access to the Internet or intranet via TCP/IP, an ISP for Internet access, and access to web-published databases limited to 10 IP addresses per rolling 12-hour period.

FileMaker Pro 5.0 — Windows: Intel-compatible computer (486/33 or later); 16 MB of RAM; Windows 95 or Windows 98, or Windows NT 4 (Service Pack 3); CD-ROM drive and hard drive. Web publishing requirements were the same: a host with continuous TCP/IP access, an ISP, and the same 10-IP-address limit per 12-hour period.

4th Dimension 6.5 — Macintosh: Power PC 601 processor with a hard drive and System 7.6.1 or greater with 20 MB RAM; CD-ROM drive and hard drive.

4th Dimension 6.5 — Windows: 486 or Pentium-based machine with a hard drive and one of the following: Windows 95/98 with at least 16 MB RAM, or Windows NT Workstation or Server with at least 24 MB RAM.

Two things jump out. First, 4D asked for more RAM on the Mac (20 MB vs. 16 MB) and distinguished between Windows NT Workstation and Server configurations — a sign that 4D was already being deployed in server roles. Second, FileMaker’s web publishing was metered by IP address, which tells you it was aimed at small workgroup publishing, not enterprise deployment.

Why the Requirements Differed

The gap between 16 MB and 20–24 MB was not arbitrary. It reflected a fundamental difference in what each product was.

FileMaker Pro was designed so that a non-programmer could open the application, define fields in a spreadsheet-like interface, drag a few layout elements, and start entering data. The runtime footprint was kept small because the target user was a single person on a desktop.

4D, by contrast, shipped as a full development environment. Even in the 6.5 era it included:

• A structure editor for defining tables, fields, and relations
• A method editor for writing the 4D programming language
• A form editor for designing input and output layouts
• A compiler that could turn interpreted code into a standalone application
• A client/server architecture distinct from the single-user version

Each of those subsystems consumes memory and disk. The higher requirement was the price of being a platform rather than an application.

The interpreter vs. compiler distinction

This is the concept most worth internalizing early. In 4D, you can develop and run in interpreted mode, where the 4D language is executed line by line at runtime. This is fast to iterate on but slower to execute and requires the 4D development environment to be present.

When you are ready to ship, you use the compiler to produce a standalone, double-clickable application that no longer needs the full development environment. This is conceptually similar to the difference between running a Python script through the interpreter versus distributing a compiled binary. FileMaker, in the same era, did not offer this same developer-to-standalone-application pipeline in the same way — its Runtime and Developer editions came later and worked differently.

If you are learning 4D today, understand that “compiled 4D application” is a first-class deployment target, and plan your project structure accordingly from day one.

System Requirements as a Design Signal

Reading old requirement tables is a skill. Here is how to extract meaning from them rather than just nostalgia.

Signal in the requirements	What it tells you
Separate NT Workstation vs. Server figures	The vendor expected server deployments, not just desktops
Higher RAM on one platform	The engine was likely optimized or tested first on that platform
IP-address metering for web access	Web publishing was a bolt-on, licensed per connection
CD-ROM drive listed	Distribution was physical media; no auto-update
Explicit AppleTalk mention	Pre-TCP/IP-everywhere networking was still common

The practical lesson: when you evaluate any database platform — 4D, FileMaker, Access, or a modern low-code tool — look at whether the vendor lists server configurations separately. If they do, the product is built for multi-user deployment. If they only list desktop specs, you are looking at a single-user tool that may struggle under concurrency.

Networking: Client/Server vs. File Sharing

The networking differences between the two products were arguably more consequential than the RAM figures.

FileMaker’s original sharing model was file sharing over a network — one machine opened the database file and others connected to it, with TCP/IP or AppleTalk as the transport. This is simple and works well for small teams, but it means the “server” is really just a peer machine holding a file open.

4D’s model was a true client/server architecture. The 4D Server process manages the data, handles concurrent access, and serves requests to 4D Client applications. This is closer to how PostgreSQL or Microsoft SQL Server operate, and it is why 4D could scale to larger user counts and larger data sets.

For anyone building today, the decision framework is:

• Single user or two people? A desktop database is fine.
• A handful of concurrent users on a LAN? File-sharing or a lightweight server works.
• Dozens of users, remote access, or web clients? You want a genuine client/server engine like 4D Server.

The original IP-address metering on FileMaker’s web publishing is a good illustration of the constraint: it was not built for open web traffic.

Runtimes, Compilers, and Deployment

The “differences in runtimes” and “compiler” headings in the original outline point at a real fork in the road.

• Interpreted runtime: You run inside the 4D development environment. Best for development, debugging, and internal tools where you control the machine.
• Compiled application: You build a standalone executable. Best for distribution to users who should not have the development environment.
• 4D Server: The multi-user engine. Best for shared data with concurrent access.
• 4D Client: The connecting application. Best for workstations that talk to the server.

A common mistake for newcomers is to develop everything in interpreted mode and then discover that compilation surfaces errors the interpreter tolerated. Build and compile early, even on a small test project, so you learn the compiler’s expectations before you have thousands of lines of code.

Web Hosting and Data Charting

The original outline listed “Web Hosting” and “Data Charting” as distinct topics, and both remain relevant.

Web hosting in the 4D world means exposing your database to browsers. Historically this was done through 4D’s built-in web server, which could serve HTML templates and respond to requests using the 4D language. Today, 4D also supports REST-style access and can integrate with standard web stacks, so you are not locked into a proprietary publishing model. If you are planning a web front end, decide early whether you will render pages server-side in 4D or expose data via REST to a separate front-end framework.

Data charting means turning query results into graphs and dashboards. 4D has historically offered charting through its form objects and third-party plug-ins. The practical guidance: keep your reporting queries separate from your data-entry forms, because reporting workloads have very different performance characteristics than transactional ones.

Plug-ins, Tools, and the Ecosystem

The original outline’s “Plug ins,” “Tools/Utilities,” and “Resources” headings acknowledge something important: no database platform is used in isolation.

• Plug-ins extend 4D with capabilities the core does not provide — specialized file formats, hardware integration, advanced graphics.
• Tools and utilities cover everything from code analysis to data repair.
• Resources — documentation, forums, and community sites — are where you actually learn the platform.

For authoritative background on the broader category, see the Wikipedia article on database management systems and the relational model that underpins both 4D and FileMaker. For the language and platform lineage, the 4D (programming language) entry is a reasonable starting point. And for the standards that modern 4D interoperates with, the SQL overview is worth reading even if you spend most of your time in 4D’s native language.

How to Decide: A Practical Framework

If you are choosing or inheriting a platform, work through these questions in order.

1. How many concurrent users? One or two means a desktop tool. More than a handful means you need a real server engine.
2. Do you need to distribute a standalone app? If yes, you need a platform with a compiler, which 4D provides.
3. Will there be a web or mobile front end? If yes, favor a platform with REST or SQL access.
4. How much custom logic? Heavy business rules favor a programmable environment over a form-driven one.
5. What is your team’s skill set? A citizen developer will be productive faster in FileMaker-style tools; a programmer will prefer 4D’s method editor.

There is no universally correct answer. The right choice depends on the shape of the problem, not on which product has the bigger feature list.

Frequently Asked Questions

Is 4D the same thing as 4th Dimension?

Yes. “4D” is the modern name for the product originally called “4th Dimension.” The name was shortened over the years, but the platform, the language, and the development environment are the same lineage. Documentation and community posts from the 1990s and 2000s use “4th Dimension,” while current material uses “4D.”

Why did 4th Dimension need more RAM than FileMaker Pro?

Because 4D shipped as a complete development environment — structure editor, method editor, form editor, compiler, and client/server components — while FileMaker Pro was positioned as an end-user database application. More subsystems running at once means a larger memory footprint. The higher requirement was a consequence of being a platform rather than a single application.

What is the difference between interpreted and compiled mode in 4D?

In interpreted mode, the 4D language is executed line by line at runtime, which is convenient for development but slower and requires the development environment. In compiled mode, the compiler translates your code into a standalone application that runs without the development environment and executes faster. Most production deployments use compiled applications or 4D Server.

Can 4D databases be published on the web?

Yes. 4D has long included a built-in web server capable of serving pages and responding to requests using the 4D language, and modern versions also support REST-style access and integration with standard web stacks. The original FileMaker comparison metered web access by IP address, which reflected a small-workgroup publishing model rather than open web traffic.

Do the old system requirements still apply?

No. The figures in the original comparison — 16 MB of RAM, Windows 95/98, Mac OS 7.6.1 — describe hardware and operating systems from roughly 1999–2000. Modern 4D releases run on current versions of macOS and Windows and require far more memory, as you would expect from any contemporary database platform. Treat the old table as a historical baseline, not a buying guide.

What should a beginner learn first in 4D?

Start with the structure editor: tables, fields, and relations. Everything else — forms, methods, value lists, reports — is built on top of that data model. Once you can define a clean relational structure, move to the method editor and learn how the 4D language reads and writes records. Forms and value lists come naturally after that, because they are just presentation layers over the structure you already designed.