Skip to main content

​
File Naming Convention

API definition files follow a strict naming pattern:
  • Format: <module_name>.api
  • Location: apis_def/ directory
  • Examples: user32.api, kernel32.api, ntdll.api
The filename must match the DLL module name (without the .dll extension) that contains the API functions.

​
INI-Based Structure

API definition files use the INI file format with sections for each function: 
[FunctionName]
1=PARAMETER_TYPE parameterName
2=PARAMETER_TYPE parameterName
ParamCount=2
Header=header1.h.api;header2.h.api;
@=FunctionName

​
Basic Function Definition

Here’s a simple example from user32.api: 
[GetClientRect]
1=HWND hWnd
2=LPRECT lpRect
ParamCount=2
Header=windows.h.api;
@=GetClientRect

​
Field Breakdown

​
[FunctionName]
Section Header
required
The section name must exactly match the exported function name from the DLL.
​
1, 2, 3...
Parameter Lines
required
Numbered lines define each parameter in order:
  • Number corresponds to the parameter position (1-based)
  • Format: TYPE parameterName
  • Types can be base types (DWORD, LPSTR) or custom types in [brackets]
​
ParamCount
Integer
required
Total number of parameters the function accepts. Use 0 for functions with no parameters.
​
Header
String
default:"none"
Semicolon-separated list of header files containing type definitions referenced by this function.
​
@
String
required
The canonical function name. Usually matches the section name but can differ for aliases.

​
Functions With No Parameters

Functions that take no parameters still need a definition: 
[GetDesktopWindow]
ParamCount=0
@=GetDesktopWindow

[IsDebuggerPresent]
ParamCount=0
@=IsDebuggerPresent

​
Custom Type References

Parameters with custom types (enums or flags) use bracket notation: 
[SendMessage]
1=HWND hWnd
2=[WinMsg] Msg
3=WPARAM wParam
4=LPARAM lParam
ParamCount=4
Header=windows.h.api;
@=SendMessage
The [WinMsg] notation indicates:
  • Msg is the parameter name
  • WinMsg is a custom type defined in windows.h.api
  • xAnalyzer will resolve values to symbolic constants (e.g., WM_CLOSE, WM_PAINT)

​
Complex Example: MessageBox

Here’s the complete definition for MessageBox from user32.api: 
[MessageBox]
1=HWND hWnd
2=LPCTSTR lpText
3=LPCTSTR lpCaption
4=[MessageBoxType] uType
ParamCount=4
Header=shell.h.api;windows.h.api;
@=MessageBox
This definition tells xAnalyzer:
  • Parameter 1: hWnd is a window handle
  • Parameter 2: lpText is a string pointer (message text)
  • Parameter 3: lpCaption is a string pointer (title bar text)
  • Parameter 4: uType uses the MessageBoxType enum from shell.h.api
  • Referenced types are in shell.h.api and windows.h.api

​
Multiple Headers

Functions can reference multiple header files: 
[CreateWindowEx]
1=[WindowExStyle] dwExStyle
2=LPCTSTR lpClassName
3=LPCTSTR lpWindowName
4=[WindowStyle] dwStyle
5=[CreateWindow_CW] x
6=[CreateWindow_CW] y
7=[CreateWindow_CW] nWidth
8=[CreateWindow_CW] nHeight
9=HWND hWndParent
10=HMENU hMenu
11=HINSTANCE hInstance
12=LPVOID lpParam
ParamCount=12
Header=user32.h.api;gdi.h.api;windows.h.api;
@=CreateWindowEx
xAnalyzer will search all listed headers for type definitions like WindowExStyle and WindowStyle.

​
Advanced: Debugging Functions

From kernel32.api, here’s a debugging-related function: 
[CheckRemoteDebuggerPresent]
1=[ProcessHandle] hProcess
2=PBOOL pbDebuggerPresent
ParamCount=2
Header=windows.h.api;
@=CheckRemoteDebuggerPresent

[GetThreadContext]
1=[ThreadHandle] hThread
2=LPCONTEXT lpContext
ParamCount=2
Header=kernel32.h.api;windows.h.api;
@=GetThreadContext

​
Best Practices

Function and parameter names should exactly match Microsoft documentation for consistency.
Define every parameter, even simple ones like DWORD or LPVOID. Complete definitions provide better analysis.
Always include the Header field when using custom types to ensure xAnalyzer can resolve them.
Use consistent type names across definitions. If one function uses [ProcessHandle], others should too.

​
Common Patterns

​
Handle Types

1=[ProcessHandle] hProcess
2=[ThreadHandle] hThread
3=HWND hWnd
4=HDC hDC

​
String Parameters

1=LPCTSTR lpString      ; Input string
2=LPTSTR lpBuffer       ; Output string buffer
3=int nMaxCount         ; Buffer size

​
Flag and Enum Parameters

1=[AccessRights] dwDesiredAccess
2=[CreationFlags] dwCreationFlags
3=[FileAttributes] dwFlagsAndAttributes

​
Validation Checklist

Before adding a new definition, verify:
  • Section name matches the exported function name
  • Parameters are numbered sequentially starting from 1
  • ParamCount matches the actual number of parameters
  • Custom types are enclosed in brackets
  • All referenced types have entries in the specified header files
  • Header field ends with a semicolon
  • @ field is present and correct

​
Next Steps

Creating Definitions

Step-by-step guide to writing custom definitions

Header Files

Learn about enum and flag definitions

Build docs developers (and LLMs) love

Get started for freeTalk to us