Classic Visual Basic
Enable an AI agent to recognise a Classic Visual Basic artefact, assess its build and execution constraints, and decide which inspection, maintenance, integration or migration actions are justified.
Research draft, second pass
A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.
Researched by: Codex + Grok
Purpose and description
Enable an AI agent to recognise a Classic Visual Basic artefact, assess its build and execution constraints, and decide which inspection, maintenance, integration or migration actions are justified.
Classic Visual Basic is Microsoft's event-driven, COM-based BASIC programming language and RAD environment (versions 1.0-6.0, 1991-1998) that compiled to native Windows executables and ActiveX components rather than to the .NET Common Language Runtime.
It can be Classify an artefact as Classic Visual Basic and qualify the classification by version evidence.; Reconstruct a project's source, designer and dependency inventory.; Trace form events, default instances and error paths for a specified maintenance task.; Assess whether an identified environment can build, activate and exercise the artefact.; Evaluate a proposed change against COM consumers, persisted resources and observed behaviour.; Plan a bounded repair, interoperability wrapper or migration experiment with explicit acceptance checks..
Distinguishing features
Identify the producing toolchain and target runtime: a Classic Visual Basic classification requires evidence of a pre-.NET Visual Basic lineage rather than relying on BASIC-like syntax.
For a suspected VB5 or VB6 project, inspect .vbp metadata and associated .bas, .cls, .frm and designer resources; extensions alone do not establish the dialect.
Distinguish a standalone Visual Basic project from VBA code embedded in a host document or application, even where syntax and referenced COM objects overlap.
Distinguish Visual Basic project and designer artefacts from VBScript text executed by a scripting host.
For later Windows editions, inspect project-type, compilation and COM metadata to distinguish Standard EXE and ActiveX outputs; do not assume these categories apply to every earlier release.
Scope
+ Classic Visual Basic dialect, product version and project-type identification
+ Source modules, forms, designer resources and project composition
+ Event-driven behaviour, state handling and language-specific error semantics
+ COM and ActiveX contracts, references and component compatibility
+ Build reproducibility, runtime dependencies and maintenance constraints
- Visual Basic .NET language and CLR application models
- VBA host applications, macro containers and host-specific object models
- VBScript execution hosts and script deployment
- Business-domain rules implemented by an individual application
- General Windows administration and operating-system lifecycle management
- Database schemas and external services consumed by the application
Characteristics
- Dialect and product lineage
- Recorded Visual Basic version, edition and platform; unresolved when evidence is insufficient Determines which syntax, project formats, controls and build assumptions apply.
- Project output type
- Version-specific project type, such as Standard EXE, ActiveX EXE, ActiveX DLL or ActiveX Control; unknown Separates standalone execution from component activation and control hosting.
- Available artefact coverage
- Source and designer resources complete; partially available; binary only; unverified Limits what the agent can inspect, reproduce or safely change.
- Compilation mode
- P-code; native code; other version-specific mode; unknown Affects build equivalence and the interpretation of binary inspection.
- Unresolved build references
- Count of missing or mismatched references and controls in a named build environment Provides a concrete measure of dependency work remaining before a build can be assessed.
- Component compatibility commitment
- Project linked to its compatibility baseline binary and known consuming applications, where applicable Makes interface-preservation obligations visible before a component is rebuilt.
- Observed execution status
- Not tested; activation failed; starts only; specified workflows passed; specified workflows failed Distinguishes successful startup from evidence that required behaviour still works.
- Data-access mechanism
- Observed DAO, RDO, ADO, direct API, other or none; multiple values allowed Identifies provider and deployment dependencies that source availability alone does not resolve.
Where this came from
wikidata · CC0 1.0
Drafted structure
Bundle to layer to finding to question, as the second pass will find it: 6 bundles · 11 layers · 11 findings · 26 questions.
Dialect and project identity Establish which Classic Visual Basic lineage and project form the artefact belongs to.
Similar syntax occurs in neighbouring Visual Basic technologies, while Classic Visual Basic releases do not share every capability.
Lineage evidence
Record evidence that supports the language and product classification.
Product and dialect
Capture the producing product, version and platform with the evidence and confidence behind each identification.
- Which project metadata, binary metadata or original tooling identifies the Visual Basic release and platform? provenance
- What evidence distinguishes this artefact from VBA, VBScript and Visual Basic .NET? boundary
Project composition
Identify the project boundary and the files that contribute to its output.
Project membership and output
Record the declared output type, startup object, project membership and any project-group relationships.
- What output type and startup object does the project declare, and are they valid for the identified release? definition
- Which modules, forms, classes and resources are referenced but absent or available only in another project? measurement
Forms and event execution Represent the designer artefacts and event-driven execution paths that determine application behaviour.
A source-only reading can miss persisted control properties, startup behaviour and event-triggered state changes.
Designer and controls
Connect form and control definitions to their persisted resources and implementations.
Designer resource integrity
Capture form definitions, associated binary resources, control arrays and required custom controls where present.
- Which forms or user controls depend on associated binary resources, and are those resources present? measurement
- Which controls, control-array indices or persisted properties must be preserved for the designer and event bindings to remain usable? boundary
Event flow and lifetime
Record how startup, user actions and component callbacks create and mutate application state.
Event and instance semantics
Identify consequential event ordering, form default-instance use, object lifetime and re-entrancy assumptions.
- How does the startup object reach the required workflow through form, control or component events? definition
- Where could default form instances, DoEvents, timers or callbacks expose partially updated state? boundary
- Which event sequences must be exercised to validate a proposed change? action
Language and data semantics Record Classic Visual Basic behaviours that can change meaning during maintenance or translation.
Implicit conversions, legacy error handling and external data representations can preserve or break behaviour independently of apparent syntax similarity.
Values and binding
Expose consequential assumptions about types, conversions and member resolution.
Implicit value behaviour
Capture relevant use of Variant, Empty, Null, Nothing, default members, argument passing and array bounds.
- Which paths depend on Variant coercion or distinctions among Empty, Null and Nothing? definition
- Where do default members, ByRef arguments or array-bound assumptions affect externally observable results? boundary
Errors and data boundaries
Connect error recovery and external data exchange to behaviour that must be checked.
Recovery and representation
Record On Error handling and assumptions at file, database and native API boundaries.
- Which On Error and Resume paths suppress, recover from or propagate failures, and how is Err inspected? definition
- Which file layouts, database providers or Declare signatures depend on specific string encodings, numeric widths or record layouts? boundary
- What failure and round-trip examples would detect a semantic regression? action
COM and ActiveX contracts Represent imported and exported component contracts for projects that use COM or ActiveX.
A component can build successfully while failing to activate or breaking existing clients; this bundle must be marked inapplicable when the identified artefact does not use these mechanisms.
References and activation
Identify component resolution and activation requirements.
Component resolution
Record referenced type libraries, ActiveX controls and dynamically activated classes, including their resolution evidence.
- Which dependencies are declared as references or controls, and which are activated through CreateObject or GetObject? definition
- Which component identities, versions, registrations or design-time licences are required in the tested environment? measurement
Published interface stability
Identify the promises made to existing component consumers.
Compatibility baseline
Record exposed classes, members and events alongside project compatibility settings and any baseline binary.
- What compatibility setting and baseline binary govern the component build, where supported by this release? provenance
- Which existing clients rely on the exposed interfaces, activation model or events? boundary
- What interface comparison and client execution checks are required before replacing the deployed component? action
Build, runtime and change readiness Establish what can be reproduced and which maintenance actions have sufficient evidence.
Classic Visual Basic maintenance depends on recovering a specific toolchain and dependency environment, then validating behaviour beyond compilation.
Build and deployment environment
Separate build prerequisites from runtime installation and activation requirements.
Reproducible environment
Record the compiler, service level, compilation settings, controls, runtime files and installation steps needed for a named environment.
- Which toolchain version, compilation mode, conditional compilation constants and dependency versions produced the reference build? provenance
- Which prerequisites are required only for development, and which must exist on the execution machine? boundary
- Can the available inputs produce an executable or component that passes the defined activation and workflow checks? measurement
Maintenance decision
Tie repair, wrapping and migration choices to specific behaviour and dependency evidence.
Bounded change readiness
Capture the proposed intervention, its affected semantics and contracts, and the checks needed to accept or reverse it.
- Which forms, error paths, data representations and COM contracts would this intervention affect? boundary
- What observed workflows and consumer checks define acceptance for repair, wrapping or migration? action
- Which reference binaries, installers and data fixtures must be retained to compare results and restore the prior deployment? action
Evidence and external alignment What the world already says about this thing, gathered so the model can be checked against it.
A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.
Reported evidence
Findings from the breadth pass, kept separate from the structural claims.
Kinds and varieties
Reported by the breadth pass; each item needs checking against its source before it becomes normative.
- Visual Basic 1.0-3.0 (16-bit Windows)
- Visual Basic 4.0 (16-bit and 32-bit)
- Visual Basic 5.0
- Visual Basic 6.0 / VB6
- Visual Basic for Applications (VBA)
- VBScript
- Visual Basic .NET (not classic; successor)
- Embedded/CE variants
- Which of these kinds and varieties hold for the sense of Classic Visual Basic this model covers, and on what evidence? provenance
What the second pass must settle
- Does the registry intend Classic Visual Basic to include every pre-.NET release and platform, including Visual Basic for DOS, or specifically the later Windows product family?
- Which authoritative, version-specific documentation should support the model's project types, compilation modes and language semantics?
- Which current operating-system, runtime, IDE and third-party control combinations have documented support, and which merely have observed successful execution?
- How should the model express confidence for binary-only artefacts when the producing release, source completeness or compatibility baseline cannot be recovered?
- Which existing Vercy models already own COM contracts, Windows deployment and language migration, and what relations should avoid duplicating those responsibilities?