At the core of professional Excel development is the need to safeguard intellectual property while maintaining robust functionality. VBA to DLL compilation serves as the flagship feature of DoneEx VbaCompiler for Excel, providing an advanced technical solution to a long-standing vulnerability.

This process fundamentally transforms how macros are stored and executed. Instead of leaving human-readable Visual Basic for Applications (VBA) source code embedded inside a spreadsheet, the compiler converts the logic into a binary Windows Dynamic Link Library (DLL) file. During this VBA compilation workflow, the original source code text is completely removed from the Excel workbook. It is replaced with secure, automated call procedures that link directly to the compiled DLL. This ensures that the Excel workbook or add-in retains 100% of its original calculations, automation, and operational behavior, while the underlying algorithmic logic is completely detached from the user-facing file.

Original VBA code example:

Option Explicit
#If Win64 Then
Private Declare PtrSafe Function getFrequency Lib "kernel32" _
Alias "QueryPerformanceFrequency" (cyFrequency As Currency) As Long
Private Declare PtrSafe Function getTickCount Lib "kernel32" _
Alias "QueryPerformanceCounter" (cyTickCount As Currency) As Long
#Else
Private Declare Function getFrequency Lib "kernel32" _
Alias "QueryPerformanceFrequency" (cyFrequency As Currency) As Long
Private Declare Function getTickCount Lib "kernel32" _
Alias "QueryPerformanceCounter" (cyTickCount As Currency) As Long
#End If
Private Function Leibniz(n As Long) As Double
    Dim i As Double       ' Number of iterations and control variable
    Dim s As Double       'Signal for the next iteration
    Dim pi As Double
    s = 1
    pi = 0
    
    i = 1
    While i <= (n * 2)
        pi = pi + s * (4 / i)
        s = -s
        i = i + 2
    Wend
    Leibniz = pi
End Function
Function RunLeibniz()
    Dim calcTime As Double
    Dim t As Double
    Range("C2").Value = "Please wait..."
    Range("c3").Value = "Please wait ..."
    DoEvents
    DoEvents
    t = MicroTimer
    RunLeibniz = Leibniz(1000000000)
    calcTime = MicroTimer - t
    Range("c2").Value = RunLeibniz
    Range("c3").Value = calcTime
End Function
Private Function MicroTimer() As Double
    'Returns seconds.
    Dim cyTicks1 As Currency
    Static cyFrequency As Currency
    MicroTimer = 0
    ' Get frequency.
    If cyFrequency = 0 Then getFrequency cyFrequency
    ' Get ticks.
    getTickCount cyTicks1
    ' Seconds
    If cyFrequency Then MicroTimer = cyTicks1 / cyFrequency
End Function
Private Function WPi(n As Long) As Double
    Dim i As Double         ' Number of iterations and control variable
    Dim pi As Double
    pi = 4
    i = 3
    While i <= (n + 2)
        pi = pi * ((i - 1) / i) * ((i + 1) / i)
        i = i + 2
    Wend
    WPi = pi
End Function

Function RunTest()
    Dim t As Double
    t = Timer
    RunTest = WPi(2000000000)
    Debug.Print Timer - t & " sec"
End Function

The same module content after VBA to DLL compilation:

#If Win64 Then
Private Declare PtrSafe Function s4fcdelgl0c6nor Lib "ApproxPi_xls_64.dll" Alias "g3x4rjxv" () As Variant
Private Declare PtrSafe Function o3qhs5n91rwz Lib "ApproxPi_xls_64.dll" Alias "j0d04ababt" () As Variant
#Else
Private Declare Function s4fcdelgl0c6nor Lib "ApproxPi_xls_32.dll" Alias "_h2uwzrz0@0" () As Variant
Private Declare Function o3qhs5n91rwz Lib "ApproxPi_xls_32.dll" Alias "_m1zs64fq@0" () As Variant
#End If
Option Explicit
Function RunLeibniz()
RunLeibniz = s4fcdelgl0c6nor()
End Function
Function RunTest()
RunTest = o3qhs5n91rwz()
End Function

Folder with the ApproxPi.xls workbook, the VBA to DLL compilation result example files :

The Critical Need for VBA Code Protection

Relying on native Excel features to secure proprietary macros introduces severe operational risks. The standard VBA project passwords provided by Microsoft Excel are inherently weak. They do not encrypt the source code; rather, they merely act as a superficial lock. Anyone with a basic text editor, hex editor, or access to free online decryption tools can bypass or strip a VBA password in a matter of seconds.

For businesses, independent developers, and financial institutions, implementing robust VBA code protection is vital. Organizations regularly build highly sophisticated financial models, proprietary trading algorithms, and automated corporate workflows inside Excel. If left unprotected, this intellectual property can be easily stolen, altered, or redistributed without authorization. Beyond intellectual property theft, uncompiled code exposes corporate infrastructure to regulatory compliance failures and security vulnerabilities. Utilizing a dedicated tool to compile VBA code establishes a definitive, professional barrier against reverse engineering, ensuring that your commercial secrets and proprietary logic remain strictly confidential.

Why VBA Compiled to DLL Outperform Standard Excel Security

From Vulnerable VBA Script to DLL Machine Code

The structural difference between native VBA and a compiled binary file represents a massive leap in VBA code security. Native VBA is stored as plain text or interpreted intermediate code within the .xlsm or .xlsb archive structure. Because the file format is openly documented, extracting the macro architecture requires very little technical effort.

In contrast, converting VBA to DLL translates high-level code into low-level machine code. The resulting binary file contains no human-readable variable names, logic strings, or comments. Because machine code consists purely of compiled instructions optimized for the Windows operating system, decompiling the DLL back into its original VBA syntax is practically impossible.

Eliminating Password-Cracking Risks

By shifting the application architecture from standard scripts to a compiled binary, you effectively move the security perimeter. Instead of relying on the easily compromised Excel application level, your code is protected at the robust Windows OS and binary execution level.

A compiled DLL offers several distinct advantages over native workbooks:

• No Script Exposure: The file cannot be unzipped, inspected, or viewed using standard Excel development tools or macro viewers.
• Immunity to Password Crackers: Because there is no VBA password to break within the workbook for the compiled logic, automated password-stripping utilities become completely useless.
• Tamper Prevention: Users cannot accidentally or intentionally modify the core business logic, preventing version fragmentation and unauthorized alterations to critical models.

When you protect VBA code through true binary compilation, you eliminate the vulnerabilities of script-based execution. Secure your proprietary Excel models today by downloading a trial of VbaCompiler for Excel.

The post VBA to DLL Compilation appeared first on VbaCompiler for Excel.

You can speed up VBA heavy algorithms by compiling them into a DLL (Dynamic Link Library) file using DoneEx VBA Compiler for Excel. A process that once took minutes in Excel can now suddenly finish in seconds.

But why does this happen? The secret lies in moving from a line-by-line interpreter to native machine code.

VBA Bytecode (P-Code) Tokenization of Algorithms vs. DLL Native Machine code

Bytecode (P-Code) Tokenization is a phase where human-readable source code is translated into a highly compact, stream-lined series of numeric codes (tokens) representing operations and operands.
Instead of executing text directly or compiling all the way down to native machine code, the language environment creates an intermediate representation (IR) designed to be easily read by an interpreter loop.
To understand the speed difference, we have to look at how the CPU interacts with the instructions.

The VBA Side: The P-Code Virtual Machine

Standard VBA does not compile into machine code; it compiles into P-Code (Packed Code or Pseudo-Code).

1. The Virtual Machine: When you run a macro, Excel spins up an internal virtual machine (the VBA runtime engine, VBE7.dll).
2. The Fetch-Decode-Execute Loop: The CPU cannot read P-Code. Therefore, VBE7.dll must run a continuous software loop. It fetches a P-Code token (e.g., an instruction to add two numbers), decodes what it means using a giant internal lookup table (switch statements in C++), and then executes the corresponding native machine code pre-written inside the runtime.
3. The Overhead: A simple operation like x = x + 1 takes dozens of actual hardware CPU cycles just to parse, validate, and execute through the interpreter layer.

The DLL Side: Direct Registers and Native Opcodes

When you rewrite the algorithm in a language like C++ or Rust and compile it to a DLL, the compiler completely bypasses the need for a runtime virtual machine. Skipping the runtime virtual machine of VBA code can speed up those algorithms.

1. Direct Compilation: The compiler analyzes your entire syntax tree and translates your algorithms directly into Native x86/x64 Machine Code (Opcodes).
2. Hardware Optimization: Your variables are mapped directly to physical CPU registers (like RAX, RCX), and operations become single hardware instructions (like ADD, MOV).
3. No Middleman: When Excel calls the DLL function, control of the instruction pointer is handed directly to the CPU. The hardware runs the code at its maximum physical clock speed with zero translation layer.

Key Technical Advantages of the DLL

Beyond removing the interpreter loop, a compiled DLL gains several low-level optimizations that VBA simply cannot perform:

• Static Type Binding vs. Variant Overhead: VBA heavily relies on IDispatch interfaces and dynamic type checking. Even if you define variables explicitly, the VBA runtime constantly performs safety checks at runtime to prevent type mismatches. A native compiler resolves types entirely at compile time, completely stripping out runtime type-checking overhead.
• Advanced Compiler Optimizations: Modern compilers (like MinGW GCC or MSVC) perform aggressive optimizations during compilation that a runtime interpreter cannot afford to do on the fly:
  • Loop Unrolling: Duplicating loop bodies to minimize the overhead of branch predictions and counter increments.
  • Vectorization (SIMD): Packing data so that a single CPU instruction can operate on multiple data points simultaneously (e.g., adding four pairs of numbers in a single clock cycle).
• Memory Alignment and Cache Efficiency: VBA manages memory through the COM (Component Object Model) heap, which often leads to fragmented data. A compiled DLL can allocate tightly packed, contiguous memory blocks. This maximizes CPU Cache Locality (keeping data in L1/L2 cache), ensuring the processor doesn’t stall waiting for data to travel from the slower system RAM.

The post Speed Up VBA Algorithms appeared first on VbaCompiler for Excel.

If you are distributing a high-value Excel workbook protected only by a standard VBA password, your code is essentially open-source—your Excel macros are not secure! Within seconds, an unauthorized user can strip Excel’s native locks and gain full access to your proprietary macros, and business logic. To truly protect your intellectual property, you need to treat your workbook like professional software. Compiling your spreadsheet using DoneEx VbaCompiler transforms fragile VBA code into a native Windows DLL, effectively building an impenetrable black box. Here is a look at the heavy-duty security mechanisms—from run-time integrity checks to selective API exposure—that turn an ordinary Excel file into a secure, commercial-grade application.

An analysis of the advanced security mechanisms applied to Excel workbooks compiled with DoneEx VbaCompiler for Excel:

Secure Excel Macros Through Code Inaccessibility & Decompilation Prevention

• VBA-to-C-to-Binary Transformation: Unlike standard tools that merely hide or obfuscate code, the compiler converts the source VBA code into C-language code, which is then compiled into a native Windows binary DLL file using an integrated C-compiler (like MinGW GCC or Microsoft Visual C).

   

• Complete Code Elimination: During the final phase of compilation, the original VBA code bodies are entirely removed from the workbook. They are replaced with a minor “connective VBA code” (or wrapper bridge) that merely calls functions from the compiled DLL. This is key to making the Excel macros secure, because if a hacker cracks open the Excel VBA Editor, there is no logic to steal.

   

• Impenetrable to VBA Decompilers: Because the logic is entirely housed in a compiled Windows DLL, it cannot be reversed back into readable VBA source code. This eliminates the threat of standard VBA password removal tools or MS Office VBA decompilers.

   

• Anti-Tracing Protection: The binary conversion ensures that malicious users cannot trace, pause, or observe execution flows or variable values via the Visual Basic Editor (VBE) debugging tools.

   

• Run-Time Binary Code Integrity Verification: To secure Excel macros against active hacking attempts and memory patching, the compiled workbook utilizes a sophisticated anti-tampering mechanism. During execution, the native binary code continuously monitors and verifies its own integrity. If a malicious actor attempts to modify the compiled DLL on disk, alter the binary structure, or inject code into the active memory space to bypass security restrictions, the runtime integrity check will instantly detect the anomaly. Upon detecting tampering, the application will automatically halt execution, neutralizing the threat before any proprietary logic can be compromised.

   

• Selective API Exposure & Attack Surface Reduction: To prevent malicious actors from mapping out the internal structure of the compiled application, the compiler utilizes a “Method Expose Mode“ driven by the [DNXVBC_VBA_EXPOSED_METHOD] compile-time attribute. By default, standard compilation might leave function names visible in the DLL’s Export Table or the connective VBA wrapper. By using this attribute, developers can precisely control the visibility of their compiled methods. Unmarked methods are entirely stripped from the public-facing DLL API and the connective VBA code, leaving only the essential entry points visible. This drastically minimizes the application’s attack surface and stops attackers from analyzing the workbook’s internal mechanics through API scanning.

   

• Static Analysis Defense: To prevent attackers from extracting sensitive text data via static binary analysis, the compiler encrypts all string literals and text values into a secure dictionary during compilation. These strings remain entirely encrypted on disk. The decryption key and dictionary are only loaded into memory after the application successfully launches and passes all registration, licensing, and credential verifications. This ensures that unauthorized users cannot scan the DLL for proprietary messages, SQL connection strings, or internal variables

Workbook Hardening & Project Integrity

• “Unviewable VBA” Option: The software can lock the VBA project structure completely, rendering the project “unviewable” within Excel. This prevents unauthorized users from altering or tampering with the newly generated connective VBA wrapper code.

   

• Original File Extension Maintenance: The final secured file retains its native extension (.xlsm, .xlsb, .xlam, etc.). This means it acts like a normal spreadsheet rather than an suspicious .exe file, lowering user friction while maintaining internal structural protection.

   

• Single-File Consolidation (Embedded DLL): For easier distribution and a cleaner security profile, the compiler allows the Windows DLL to be embedded natively into the compiled workbook itself. Upon launching the workbook, the file automatically extracts the DLL into memory or a temporary path, reducing the risk of a user intercepting or substituting the DLL file externally.

Copy Protection & Licensing Control

• Hardware Locking (Computer ID Binding): Users can enforce a strict copy protection mechanism. When a client opens the compiled workbook, it checks for a registration key. If missing, it generates a unique Computer ID based on the target machine’s hardware profile. The workbook will refuse to run unless the author provides a matching activation key tailored exclusively to that hardware profile.

   

• Physical Copy Control: While the file itself can still be copied physically from one computer to another, the functionality of the file is frozen. Copies placed on unauthorized computers will automatically block execution.

Time-Bombing, Trials, and Keeping Excel Macros Secure Through Distribution Management

• Time-Limited Registration Keys: The compiler includes a built-in “Registration Key Tool” allowing the author to set specific expiration windows (“date from” and “date to”) for compiled workbooks. Once the timeframe lapses, the DLL ceases execution.

   

• Trial/Demo Functionality: Authors can configure a limited trial period (e.g., access for a specific number of days) without requiring initial registration, automatically locking down the core calculations after the trial expires.

   

• Freemium Tiers: You can selectively compile specific advanced macros or procedures into the locked DLL while leaving basic macros open, establishing gated features for monetization.

Infrastructure & Environment Security

• Virtual Machine (VM) Blocking: To prevent attackers from reverse engineering licensing systems or cloning authorized environments, the software can actively block the compiled workbook or add-in from running inside virtualized environments (VMs).

   

• Digital Signatures Support: The compiler architecture allows authors to apply digital signatures directly to the compiled DLL file. This provides cryptographic proof of identity and code integrity, heavily mitigating anti-virus false positives and preventing malicious code-injection into your DLL.

   

• Customized Runtime Error Obfuscation: Standard VBA error messages often leak variable names, module titles, and structural logic. By shifting code execution to the DLL and utilizing customized runtime messages, any error reporting is securely controlled by the developer.

   

Distributing commercial or proprietary Excel workbooks with standard VBA passwords—or even text obfuscation—is no longer a viable security strategy. True intellectual property protection requires shifting from application-level hiding to operating-system-level hardening. By converting vulnerable VBA into a native Windows binary DLL, DoneEx VbaCompiler eliminates the source code from the workbook entirely. With built-in run-time integrity checks, copy protection, and precise API exposure control, compilation transforms a fragile spreadsheet into a self-defending, commercial-grade software application.

The post Security Measures to Secure Excel Macros appeared first on VbaCompiler for Excel.

The most important part of VBA code protection is preventing anyone from viewing or accessing the source code. By compiling the VBA project into a binary DLL format, the code is fully hidden and protected from unauthorized access.

Another key benefit is that you can control how their compiled solution is distributed. This is managed through the VbaCompiler registration key system.

When a protected Excel VBA application starts, the VbaCompiler runtime automatically checks the registration key provided to the user. If the key is present and valid, the compiled VBA application runs normally.If the key is not valid, the application will not be authorized to run.

To prevent unauthorized access, VbaCompiler uses a registration key sub-system. When you compile your workbook using the “Copy Protection with Registration Key” option, the protected workbook cannot be opened or run without a valid registration key.Registration keys can only be generated by you, giving you full control over who is allowed to use the workbook.

By enabling the “Hardware Locking” option in Copy Protection, you can ensure that each registration key is tied to a specific computer. This means the generated registration key will only work on the computer for which it was created, preventing it from being used on other devices.

How Excel File Copy Protection Works

Follow these simple steps to activate and secure your Excel VBA application for a specific customer computer:

1. Compile your Excel workbook or add-in

Use VbaCompiler for Excel and enable both the Copy Protection with Registration Key and Hardware Locking options during compilation.

2. Distribute the protected file

Send the compiled workbook or add-in to your customer.

3. Customer launches the product

When the customer opens the workbook or activates the add-in for the first time, a message will appear indicating that no registration key has been found. The message will display the computer’s unique Computer ID and include a Copy Computer ID button.

4. Customer sends the Computer ID

The customer clicks Copy Computer ID and sends the copied ID to you via email or any other communication method.

5. Generate the registration key

After receiving the Computer ID, open the Registration Key Tool, enter the customer’s Computer ID, and generate a unique registration key for that computer.

6. Send the registration key to the customer

Provide the generated registration key file to the customer.

7. Activate the product

The customer places the registration key file in the same folder as the compiled workbook or add-in. Once the key is detected, the product will run normally and will be licensed exclusively for that specific computer.

Video Tutorial

The post Excel workbook or add-in copy protection appeared first on VbaCompiler for Excel.

What is the Hardware Locking Option?

The Hardware Locking option is a security configuration within VbaCompiler for Excel that restricts your compiled workbook or add-in to a single, designated computer. It works in tandem with the Copy protection with registration key feature to create a Node-Locking licensing framework.

Without this option enabled, a compiled Excel file could be copied, emailed, or distributed online, allowing unauthorized users to open and run your application freely on their own devices. By activating Hardware Locking, you establish strict Excel Workbook DRM. Even if a user copies the file onto another machine, the application will detect the environment change and refuse to run without a separate, valid activation key tailored specifically to that new system.

Why is Hardware Locking Required for Excel File Licensing?

Excel files are notoriously easy to replicate and distribute. Standard VBA project password protection can be bypassed or cracked within minutes using widely available tools. While binary compilation strips away human-readable source code and transforms it into an un-restorable binary format embedded inside a secure DLL, Hardware Locking adds the essential layer of Computer-Specific Activation for Excel.

This mechanism ensures that your monetization and licensing models remain intact. Whether you are selling your workbook under a single-user commercial license or managing an enterprise team deployment, Hardware Locking guarantees that a single purchased license cannot be shared or pirated across an entire organization.

What is a Computer ID and How is it Generated?

To successfully tie a compiled workbook or add-in to a specific machine, the protection system relies on a unique hardware fingerprint known as a Computer ID (CID).

The Computer ID is a unique sequence of characters generated automatically by analyzing the hardware configuration of the end-user’s device. To construct this signature, the application leverages the Windows Management Instrumentation (WMI) sub-system. The compiler queries low-level Windows system information and hardware identifiers that remain stable over time, including:

• Motherboard: Unique serial numbers and manufacturer identification markers.
• CPU: Processor-specific identifiers and hardware traits.
• Operating System Information: Specific, hardware related, Windows environment configurations.

By parsing these unique parameters through a secure algorithm, the system generates a distinct Machine Fingerprint. Because it relies on deep hardware characteristics rather than easily modifiable file properties, the generated ID accurately identifies the underlying physical computer.

Important Note on Privacy and Security: The generation and usage of the Computer ID is completely secure and safe for you and your end-users. The hardware values are processed using a one-way cryptographic hash, making it mathematically impossible to reverse-engineer or recover any personal information about the physical hardware components from the generated ID.

How Hardware-Locked Activation Keys Work

When you distribute a hardware-locked Excel application, the activation workflow follows a simple, automated process:

1. First-Time Execution: When your client opens the compiled workbook or add-in on their machine without a license file, the built-in DRM system intercepts the launch. A warning message appears indicating that the registration key is missing. Example of this message window:

2. Acquiring the Computer ID: Within this prompt, the unique Machine Fingerprint is displayed alongside a convenient “Copy Computer ID” button. The customer simply clicks this button to copy their ID to the clipboard.

3. Key Generation: The customer sends this ID to you via email or your preferred communication channel. You paste this string into the Registration Key Tool field inside VbaCompiler for Excel.

4. Activation: The tool processes the Computer ID to create a unique Hardware-Locked Activation Key (an .rkey file) dedicated exclusively to that machine. Once this key file is placed in the designated directory on the user’s computer, the application unlocks permanently for that device.

Hardware Locking Video Tutorial

The post Hardware Locking appeared first on VbaCompiler for Excel.

What Is Trial Mode?

Trial Mode creates a time-limited version of a workbook or Excel add-in compiled with VbaCompiler for Excel. The application remains fully functional during the evaluation period, but access is automatically restricted once the trial expires. After expiration, users must apply a valid registration key to continue using the product.

Unlike basic VBA-based trial mechanisms that can often be bypassed, Trial Mode is integrated into the compiled and protected VBA code, making it suitable for commercial software distribution and intellectual property protection.

How Trial Mode Works

To create a trial workbook or trial Excel add-in, the VBA project must be compiled with two options enabled:

• Copy protection with registration key
• Trial Mode

When a customer launches the application for the first time, the trial period begins. The workbook or add-in can then be used normally for the configured number of days. During this period, a trial notification window is displayed to inform the user that they are running an evaluation version.

Once the specified trial period ends:

• The workbook or add-in stops functioning.
• A notification informs the user that the trial has expired.
• The application can only be used again after a valid registration key is provided.

To help prevent abuse, VbaCompiler performs runtime date verification. If a user attempts to manipulate the system clock to extend the evaluation period, the software checks the current date through public internet time sources. If the verification process cannot be completed because internet access is blocked, an appropriate warning message is shown.

Trial Mode Configuration Options

When Trial Mode is enabled, VbaCompiler displays the Trial Version Options dialog where the evaluation settings can be customized.

Trial Expires in XX Days

This setting determines how long the trial remains active after the customer’s first launch.

Available range:

• 1 to 99 days

After the configured number of days has passed, the workbook or add-in can no longer run without registration.

Close Button Appears in XX Seconds

This option controls how long the user must wait before closing the trial notification window.

Available range:

• 0 to 15 seconds

The delay can be used to ensure that evaluation users see licensing and registration information before accessing the application.

Related VbaCompiler Options

Several VbaCompiler settings work together with Trial Mode:

Copy Protection with Registration Key

This option enables licensing support and is required for Trial Mode. Once the trial expires, a valid registration key unlocks the protected workbook or add-in.

Registration Key File Name

Allows customization of the registration key filename used by the compiled application.

Registration Key Alternative Location

Specifies an additional folder where the application can search for a registration key if it is not found in the default location.

Custom Resource Dictionary

Enables customization or translation of runtime messages shown to users, including licensing and trial-related notifications.

Runtime API Functions

For advanced scenarios, developers can use VbaCompiler Runtime API functions such as IsTrialMode() and GetTrialDaysLeft() to detect whether the application is running in VBA code trial mode and retrieve the number of remaining evaluation days. This allows custom behavior based on the current licensing state.

Trial Mode provides a straightforward way to distribute evaluation versions of protected Excel applications while maintaining control over access, licensing, and VBA code security. It is particularly useful for developers who need to offer a trial workbook or trial Excel add-in without exposing their proprietary VBA code.

The post Trial Mode appeared first on VbaCompiler for Excel.

Freemium mode is an advanced deployment feature in VbaCompiler for Excel that allows developers to offer an unregistered version of their compiled Excel workbooks or add-ins with limited or modified functionality. By utilizing this mode, users can access your core spreadsheet models or tools indefinitely without a registration key. However, the advanced or premium VBA-driven features remain locked until they purchase a valid activation key.

This strategy is highly effective for software monetization and intellectual property distribution. It gives Excel developers, financial analysts, and corporate IT managers the flexibility to showcase the value of a freemium excel add-in or freemium workbook while maintaining robust security over proprietary code algorithms.

How Does Freemium Mode Differ from Trial Mode?

While both options handle unregistered usage of a compiled file, they serve completely different distribution strategies:

• Trial Mode (Time-Bounded): When a workbook is compiled in Trial mode, the user has full access to all features but only for a restricted number of days (e.g., a 30-day trial). Once the trial period expires, the entire workbook or add-in locks down completely and cannot be used without a valid registration key.
• Freemium Mode (Feature-Bounded): This mode does not expire based on time. The unregistered user can open and use the basic components of the file indefinitely. The restrictions are functional rather than chronological. By using VBA freemium mode runtime APIs, you control exactly which macros, automated calculations, or custom ribbon tools are accessible to free users and which require a premium upgrade.

How Freemium Mode Works in Brief

When you compile your Excel project with VbaCompiler for Excel into a secure binary DLL, you can enable Freemium mode alongside your copy protection settings.

When an end-user opens the compiled workbook, the runtime environment checks for a valid registration key file. If a valid key is missing, the workbook automatically enters Freemium mode.

During runtime, your VBA code utilizes specialized API functions provided by the VbaCompiler library to dynamically alter its execution path. For instance, if the file detects it is running in an unregistered state, it can block execution of specialized financial models, display custom up-sell pop-ups, or disable specific automation macros. As soon as the user applies a valid registration key, the restriction checks resolve, immediately granting full access to all premium VBA logic.

Additional Options

To configure and customize the freemium experience for your end-users, VbaCompiler for Excel provides several dedicated interface options, command-line switches, and API functions:

1. Compilation and GUI Options

• Freemium Mode Toggle: Located within the copy protection settings when choosing “Copy Protection with registration key.” This establishes Freemium mode as the default behavior for unregistered usage rather than standard Trial mode.
• Show Freemium Message Once a Day: A dedicated option designed to prevent user fatigue. When active, the software displays the unregistered reminder or nag screen only upon the first launch of the file each day, rather than every time the workbook or add-in is opened.

2. Command Line Switches

For developers automating their compilation pipelines, Freemium behavior can be explicitly injected via the command-line interface:

• -freemium – Activates Freemium mode for the target build (must be paired with the -rkname switch).
• -nag_once_aday – Configures the build to limit the freemium registration reminder window to a single appearance per day.
• -trial_nag_delay=[seconds] – Introduces a specific countdown delay on the close button of the freemium reminder pop-up window, ensuring users notice the registration prompt.

3. Runtime API Integration

To enforce feature restrictions directly inside your Excel file, add the mdlDoneExVbaCompilerRtmAPI.bas module into your project and use the following API function:

• IsFreemiumMode() – This function returns True at runtime if the workbook is operating without a registration key under freemium rules. You can wrap premium code blocks in standard conditional statements like:

If IsFreemiumMode() Then
    MsgBox "This advanced calculation requires a premium registration key.", vbInformation, "Premium Feature"
Else
    ' Run proprietary premium macro logic here
    Call ExecutePremiumModels
End If

The post Freemium Mode appeared first on VbaCompiler for Excel.

While Excel handles basic environment translations, protecting your intellectual property using DoneEx VbaCompiler for Excel presents a unique challenge: your compiled VBA code needs to communicate runtime messages, registration prompts, and licensing alerts in multiple languages without exposing the underlying source code.

VbaCompiler solves this by leveraging a dedicated Run-Time Message (RTM) Resource Dictionary. This feature allows you to customize and translate all automated runtime interactions effortlessly.

What is Workbook Localization?

Workbook and Excel add-in localization involves translating all user-facing textual components within your spreadsheet application. This includes:

• Standard runtime error responses and alerts.
• Licensing, registration, and hardware-locking prompts.
• Trial-period expiration notifications (“nag” windows).

Hardcoding these strings directly into your VBA modules is an obstacle to internationalization and risks exposing critical logic. VbaCompiler moves these literals out of the code and manages them through external, secure resource files.

Implementing Localization with the RTM Resource Dictionary

VbaCompiler manages localized strings using a specialized Custom Resource Dictionary. This dictionary acts as a centralized translation map, replacing default English messages with the target language when the compiled workbook or add-in runs.

Step 1: Locate and Copy the Dictionary Template

Upon installing VbaCompiler for Excel, navigate to the installation directory and open the rsc sub-folder. Here, you will find template examples of the runtime resource files. Copy one of these template files to your active project working directory and rename it according to your target locale (e.g., strings_de.txt for German or strings_fr.txt for French).

Step 2: Edit the Resource Values

The resource dictionary is a plain text file encoded strictly in UTF-8 format. Open your copied file using a text editor like Microsoft Notepad.

The file structure follows a clean key-value format:

<RESOURCE_NAME>=<RESOURCE_VALUE>

To localize your workbook, adhere to the following rules:

• Modify only the right side: Edit only the <RESOURCE_VALUE> portion to the right of the = assignment sign.
• Preserve the keys: Do not alter the <RESOURCE_NAME> on the left. If a key name is modified or corrupted, the runtime library will ignore the customization and revert to the default English message.
• Keep messages on a single line: The entire text value must occupy a single continuous line in the text document. If you need to create a multi-line message box, use the \n symbol combination. VbaCompiler automatically converts \n into a line break at runtime.

Step 3: Utilize Dynamic Template Tags

Localizing an interactive application often requires injecting dynamic, real-time data into your messages. VbaCompiler supports context-aware Template Tags written in capital letters and wrapped by <? and ?>.

You can embed these directly into your translation values to provide rich information to your customers:

• <?APPNAME?>: Displays the application name configured in your compilation settings.
• <?TRIAL_DAYS_LEFT?>: Dynamically shows how many days remain in a evaluation or trial period.
• <?COMPID?>: Outputs the unique hardware-locked computer ID of the user’s machine, aiding technical support.
• <?AUTHOR_CONTACT?>: Injects the support email or contact info provided in your project options.

For example, a localized registration prompt might look like this:

STR_REG_PROMPT=Willkommen bei <?APPNAME?>. Bitte senden Sie Ihre Computer-ID (<?COMPID?>) an <?AUTHOR_CONTACT?> um einen Aktivierungsschlüssel zu erhalten.

Step 4: Apply the Dictionary in VbaCompiler

Once your translation file is complete, save it, ensuring the file encoding remains set to UTF-8 in the “Save As” options.

Open VbaCompiler for Excel, navigate to the compilation options form, and locate the Resource Dictionary field. Click on the “…” to browse to select your newly created text file.

When you click compile, VbaCompiler compiles your VBA project into a secure native Windows DLL file, natively embedding your custom RTM dictionary. Your distributed Excel workbook or add-in will now display fully localized, professional interface prompts tailored exactly to your target audience.

The post Localization appeared first on VbaCompiler for Excel.

Understanding VbaCompiler Output Formats

By default, VbaCompiler for Excel strips the original VBA source code out of your Excel file, converts it into secure C-code, and compiles it into a native Windows Dynamic Link Library (DLL).

Depending on your project configuration, the standard compilation process typically generates multiple separate components:

• The modified Excel workbook or add-in (maintaining its original extension like .xls, .xlsm, .xlsb, .xla or .xlam).
• One or two external Windows DLL files (depending on whether you targeted 32-bit Excel, 64-bit Excel, or both).

In a standard multi-file distribution setup, the host Excel file retains only a minimal amount of “connective” VBA code. This code acts as a bridge, looking for and invoking the compiled functions from the external DLL files when the file is opened.

The Power of a Single File Result

The Single file result compilation feature completely reimagines this workflow. Instead of leaving the compiled DLL files sitting outside of your spreadsheet, VbaCompiler automatically embeds the 32-bit and 64-bit DLLs directly inside your compiled Excel workbook or add-in.

When you select this option, the compiler generates a single, self-contained file that completely retains its original extension. The embedded DLL is packaged securely inside the file structure. When your user launches the spreadsheet, the connective code automatically extracts the enabled DLL into the background and runs the functions seamlessly.

Note: The Single file result option requires a Professional License.

Why a Single File Result is Best

When you deliver a workbook to a customer, user experience and operational reliability are critical. Distributing your work via a Single File Result offers distinct advantages over multi-file deployment:

1. Frictionless Customer Experience

With a multi-file setup, your customer must download a ZIP file, extract all files into the exact same local folder, and ensure they stay together. If they decide to move the spreadsheet to another directory later but forget to move the accompanying DLLs, the workbook breaks instantly. A single file result compilation eliminates this entirely. Your client receives one file, saves it anywhere on their local hard drive, and starts working immediately. They can copy, move, or rename the file without breaking dependencies.

2. Elimination of Directory Path Errors

In standard multi-file distribution, the workbook expects to find its companion DLL files in the same folder or along a strict alternative path. If a customer accidentally separates the workbook from its DLLs, Excel will throw macro errors. Embedding the DLL ensures that the spreadsheet and its operational logic are permanently unified.

How to Enable Single File Result

Activating this deployment mode is straightforward. Before running your next compilation, use the following steps:

1. Open your project settings in the VbaCompiler for Excel main interface.
2. Locate the compilation options panel.
3. Check the box labeled Single file result (Embedded DLL).
4. Set your target Excel bitness (selecting “Both 32 and 64” ensures maximum compatibility on the customer side).
5. Click Compile.
   

If you prefer automating your builds via the command line, you can achieve the exact same output by appending the -packdll switch to your compilation script.

The post Single File Result Compilation appeared first on VbaCompiler for Excel.