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
Bundle → Layer → Finding → Questions Filled
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.
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.
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.
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.
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.
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.
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.
- Which of these kinds and varieties hold for the sense of Classic Visual Basic this model covers, and on what evidence? provenance
Classifiers Filled
- Family
- Thing Registry
- Category
- Information and virtual systems
- Entry kind
- thing
- Plane
- INF
- Domain
- INF.MED
What it is Filled
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.
In 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
Out of scope
- 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
Why it exists Filled
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.
Distinguishing features Filled
- 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.
What robots and AI may and may not do Filled
Must not
- Deploy legacy components with known security flaws on exposed systems.
- Write or spread macro or script code that runs without the user's knowledge.
- Remove licence or author notices from legacy code.
- Change production systems it does not administer.
Only with a human decision
- Retiring or migrating a legacy system that a business depends on.
May
- Read, explain and maintain legacy programs written in the language.
- Help plan migration of legacy applications to supported platforms.
Moral aspects Filled
- Many organizations still depend on old systems; careless changes can stop vital services.
- Unsupported components leave users' data exposed.
Who is affected
- Users of legacy applications
- Maintainers
- Organizations depending on old systems
Owners Filled
Steward
Nobody owns programs in general; each application belongs to its owner, and the vendor holds the language's rights.
Links to other meta-models Missing, in the backlog
Not described yet. This gap is in the card backlog.
What else AI and robots need to interact with it Filled
Identity and identifiers required Filled
- Vercy registry: vr.tr.classic-visual-basic
- Wikidata: Q2378 (https://www.wikidata.org/wiki/Q2378)
Direct properties not applicable Not applicable
- Dialect and product lineage: Recorded Visual Basic version, edition and platform; unresolved when evidence is insufficient
- Project output type: Version-specific project type, such as Standard EXE, ActiveX EXE, ActiveX DLL or ActiveX Control; unknown
- Available artefact coverage: Source and designer resources complete; partially available; binary only; unverified
- Compilation mode: P-code; native code; other version-specific mode; unknown
- Unresolved build references: Count of missing or mismatched references and controls in a named build environment
- Component compatibility commitment: Project linked to its compatibility baseline binary and known consuming applications, where applicable
- Observed execution status: Not tested; activation failed; starts only; specified workflows passed; specified workflows failed
- Data-access mechanism: Observed DAO, RDO, ADO, direct API, other or none; multiple values allowed
Plane INF: no invented physical properties.
Recognition optional Filled
- Source files with extensions such as .frm, .bas and .vbp.
- Code with Sub and End Sub blocks and event handlers such as Command1_Click.
Capabilities and actions required Filled
- 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.
Hazards and failure modes required Filled
- Unsupported runtime components can have unpatched security flaws.
- Old applications may fail on newer operating systems.
Standards and interfaces not applicable Not applicable
Not applicable
The language is defined by its original implementation and documentation rather than an independent formal language standard.
Context of use required Filled
- This legacy programming language is encountered in desktop applications, business utilities and reusable software components maintained from earlier development environments.
- Work with its artifacts commonly involves understanding event handlers, form definitions, external dependencies and constraints on rebuilding or migrating existing software.
Sources Filled
- Wikidata item Q2378: Classic Visual Basic - identity and sense of the item
- Wikipedia: Visual Basic (classic) - general description of the item
Open questions
- 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?
Machine files
Provenance
thing registry research (pass 2) · unreviewed
Built from: models/things/publications/thing-q2378/spec.json