What would be a good query to give Claude to check existing codebase for 64-bit migration problems?

---

Here's a prompt designed for Claude Code, organized so Claude attacks the highest-value targets first and produces actionable output:

---

```
Audit Delphi codebase in this folder for Win32?Win64 migration issues. The code currently 
compiles and runs as Win32; I want to find bugs that will surface (silently or 
loudly) when targeting Win64. 

Work through these categories in order, and for each finding produce: file:line, 
the problematic code, why it breaks on Win64, and the suggested fix. Split units in small blocks, 
process 5-10 at the same time.

1. POINTER-SIZED INTEGER BUGS (highest priority  silent corruption)
   - Casts between Pointer/object references and Integer/LongInt/Cardinal
     (these should be NativeInt/NativeUInt on Win64)
   - Storing Self, instance references, or handles in Integer fields
   - TList, TObjectList, or custom containers using Integer where pointers are stored
   - Hash functions or comparisons that cast pointers to Integer
   - Pointer arithmetic using Integer offsets

2. WINDOWS API SIGNATURE MISMATCHES
   - SetWindowLong / GetWindowLong (must be ...Ptr variants on Win64)
   - GWL_USERDATA, GWL_WNDPROC usage  same issue
   - SendMessage / PostMessage / SendNotifyMessage where WPARAM or LPARAM 
     carries a pointer cast through Integer/LongInt
   - WM_USER+n custom messages stuffing pointers into wParam/lParam
   - Window subclassing code

3. EXTERNAL DLL DECLARATIONS
   - Every `external 'xxx.dll'` declaration: check parameter types against 
     the actual Win32 API or vendor headers
   - Look for Integer where HANDLE, LPARAM, WPARAM, SIZE_T, DWORD_PTR, 
     ULONG_PTR, INT_PTR, or pointer types are expected
   - Calling convention correctness (stdcall vs cdecl)
   - Variadic functions (problematic on Win64)

4. INLINE ASSEMBLY
   - Every `asm ... end;` block  these don't compile on Win64 at all
   - List each one with surrounding context so I can plan rewrites

5. RECORD LAYOUT AND INTEROP
   - `packed record` definitions used with external APIs (alignment differs)
   - Records passed to/from C/C++ code
   - Variant records (case ... of) where field sizes change
   - Hardcoded SizeOf assumptions or magic numbers that match 32-bit sizes

6. FILE AND STREAM I/O
   - FileSeek with Integer return (truncates >2GB)
   - TStream.Position or .Size used as Integer
   - Any code that assumes file sizes fit in 32 bits

7. THIRD-PARTY AND COM
   - COM interface definitions with Integer where pointer-sized values flow
   - Type library imports  flag any that may need regeneration
   - Third-party component usage that may not have Win64 versions

8. SUSPICIOUS PATTERNS
   - Hardcoded 32-bit constants ($FFFFFFFF, MaxInt) used as "all bits set" 
     or "invalid handle" sentinels
   - Code that assumes addresses fit in 32 bits (debug formatting, logging, 
     serialization of pointers)
   - Cardinal used where SIZE_T/NativeUInt is meant

For each category, if you find nothing, say so explicitly  don't skip silently. 
At the end, give me a prioritized fix list: must-fix-before-Win64-builds, 
likely-bugs-under-load, and stylistic-cleanup.

Don't fix anything yet  this pass is audit only.
```

---

A few notes on how to use it:

- **Run it per module, not on the whole codebase at once.** Context discipline matters here; a focused pass on 5-10 units beats a sprawling pass on 200. The two-session review pattern works well: one session does the audit per module, a fresh session reviews the consolidated findings.
- **Feed it your `external` declarations as a separate batch.** Those are the highest-bug-density area and benefit from undivided attention.
- **For the inline assembly category specifically**, ask Claude to also classify each block: "trivial (replace with Pascal)", "uses CPU-specific feature (needs intrinsic or library)", "performance-critical (needs benchmarking)". That triages the rewrite work.
- **Audit-only is deliberate.** Letting Claude both find and fix in one pass tends to produce changes that look right but mask issues you'd want to see. Separate the phases.
- **After the audit, a second prompt** worth running: *"Given the audit findings, propose a test plan with specific boundary values and high-address scenarios that would have caught these bugs at runtime."* That bridges audit ? the runtime testing strategy from earlier.
