Beyond APPLOAD: A local script manager for those of us with too many LISPs

[VicoWang]

Hi everyone,

 

I'm Vico, an architectural designer. I've found this forum incredibly helpful over the years— so many of the LISP routines shared here have become the backbone of my daily workflow.

 

But as my collection grew, one thing started driving me absolutely crazy: the APPLOAD dialog.

 

The problem (I suspect I'm not alone)

 

Managing dozens of .lsp, .fas, and .vlx files through that interface is clunky at best. You can't see what's loaded, what's conflicting, or even what half of them do without opening each file. And the Startup Suite? Let's just say it and I have a complicated relationship.

 

Then there's the real nightmare: upgrading to a new PC. You spend half a day manually rebuilding your Startup Suite, redefining aliases in acad.pgp, and fixing broken Support paths — and you still forget something.

 

My attempt at a solution

 

Over the past few months I built a tool to solve this for myself, and I thought the community here might find it useful. It's part of a side-project I've been tinkering with called VedaCAD.

The tool comes as a single compiled .vlx. By default it runs in Base mode — completely offline, no accounts, no network calls, nothing phoning home. It just sits quietly and manages your local scripts.

 

What it does:

 

• Gives you a clean UI to see all your loaded scripts in one place — no more hunting through APPLOAD.
• Lets you assign custom command aliases directly from the interface, without manually editing acad.pgp or writing wrapper LISPs.
• Has a one-click "Export Config" that builds a lightweight JSON mapping of your entire environment. Take that file (plus your LISP folder) to a new machine, hit "Import Config", and everything comes back exactly as it was — script mappings, custom aliases, and paths, bypassing the native Startup Suite entirely.

 

A couple of disclaimers

 

It's written entirely in pure AutoLISP/Visual LISP and DCL, so it should be compatible all the way back to AutoCAD 2006 — none of that "requires .NET Framework X.x" nonsense. I've personally tested it on 2006, 2014, and 2024, and it runs smoothly right across that range.

 

And again: fully air-gapped in Base mode. No telemetry, no registration nag, no "sign up to unlock." If you're paranoid about that sort of thing (I certainly am), you can verify with any network monitor like Wireshark.

 

Why I'm posting

 

I built this to scratch my own itch, and it's made my life genuinely easier. But I'm one person with one workflow — I'd be really curious to hear if this solves a real problem for anyone else, or if I've just been doing APPLOAD wrong all these years.

 

If you'd like to give it a spin, the .vlx is attached. Happy to answer questions, and very open to feedback (including the critical kind).

 

Cheers,
Vico

VedaCAD V1.0.VLX

[rlx]

It looks great , you centainly know how to lisp like a pro, thanx!

Not sure the image is getting through , ah , now it its , had to switch browser with a little less security...

 

 

 

Edited Thursday at 09:36 AM by rlx

[VicoWang]

41 minutes ago, rlx said:

It looks great , you centainly know how to lisp like a pro, thanx!

Not sure the image is getting through , ah , now it its , had to switch browser with a little less security...

 

 

 

 

THX，By the way, I noticed RlxBatch in your screenshot. Assuming that's a subroutine library or a dependency file rather than a standard command, I thought I'd share a quick "hidden feature" built into the manager:

 

If you are loading a core library that doesn't need a direct command alias to trigger it, you can leave BOTH the "Native Cmd" and "Custom Alias" fields completely blank when adding it.

 

When you do this, VedaCAD flags it as a System Library:

 

• It hides it from the main DCL listbox, keeping your UI clean and focused only on actionable commands.
• It forces the file to load immediately upon AutoCAD startup.

 

This actually ties into how VedaCAD handles performance. For standard commands (where you define an alias), the tool uses strict Demand Loading (similar to CAD's native autoload behavior, but managed internally). The actual LISP payload isn't evaluated into memory until the exact moment you type the alias.

 

This means you can throw 100+ heavy routines into the manager without increasing your AutoCAD startup time or memory footprint. But for dependency files like RlxBatch, leaving the fields blank ensures those subroutines are pre-loaded into the namespace and ready for your other scripts to call.·

 

Just thought that trick might be handy for your setup!

 

 

 

 

Edited Thursday at 10:16 AM by VicoWang

[BIGAL]

You have posted twice about the same topic, as a newbie here there is no need to do that, Admin may decide to merge your two posts together.

 

Made a comment in other post about installing new software.

[VicoWang]

2 hours ago, BIGAL said:

You have posted twice about the same topic, as a newbie here there is no need to do that, Admin may decide to merge your two posts together.

 

Made a comment in other post about installing new software.

 

Hi BIGAL,

 

First off—huge apologies for the double post! I originally stumbled across that 2007 thread, dropped a reply, and then realized it would be much better to create a dedicated thread so I could properly attach the .vlx file without hijacking the old discussion. Definitely a newbie mistake on my end, and I completely understand if the Admins merge or delete the old reply to keep the board clean. Thanks for the heads-up!

 

I just went back and read your comment on that older post regarding your Install.lsp method. Extracting a ZIP natively via LISP COM objects, automatically creating directories, and injecting Support paths and CUIx menus is an incredibly resourceful and clever solution! It proves we've all been battling this exact same deployment nightmare for decades.

 

Actually, your Install.lsp workflow is basically the spiritual predecessor to what I built with VedaCAD. The main difference is that instead of moving physical ZIP files, VedaCAD relies on pure mapping logic:

 

At the atomic level, a 6-character VCID resolves a single asset. To migrate a whole PC, it simply compiles a list of those VCIDs into a lightweight config profile to batch-restore your entire setup. Scaled up for enterprises, it dynamically syncs environments based on user permissions. The engine handles all the file routing natively in the background.

Since you clearly have a deep history with this community (20k+ posts is incredible), I actually have a question for you:

 

Historically, the vast majority of AutoLISP routines and CAD tools have been strictly local. From your perspective, how far has the landscape evolved regarding web-connected or cloud-synced plugins? Are there many developers successfully exploring REST APIs or cloud-fetching inside AutoCAD nowadays, or is the community still heavily leaning toward local, air-gapped deployments?

 

I'd genuinely love to hear your thoughts on where the ecosystem is heading.

[lucas0510_12311]

i got .vlx file and i dont know the command pls

[Nikon]

30 minutes ago, lucas0510_12311 said:

i got .vlx file and i dont know the command pls

Type VC to start.

Read it on the command line when loading .VLX.

Edited 19 hours ago by Nikon

[BIGAL]

@VicoWang I don't do anything with the clous but I know some of my clients are going that way for various reasons, in the very simple way the Install.lsp works there is no reason why the programs etc can not be loaded to the cloud. You only need correct support paths hopefully set, I don't use the cloud.

 

One other thing is we had laptops where I worked, so when outside in the field the user would select the correct icon on the desktop, we had two icons "In office" and "Out of office" then the correct profile was loaded. The "out of office" would look on the laptop for programs etc, Yes had a slightly different set of menu's. The profile choice is in the ICON properties.

 

[VicoWang]

3 hours ago, BIGAL said:

@VicoWang I don't do anything with the clous but I know some of my clients are going that way for various reasons, in the very simple way the Install.lsp works there is no reason why the programs etc can not be loaded to the cloud. You only need correct support paths hopefully set, I don't use the cloud.

 

One other thing is we had laptops where I worked, so when outside in the field the user would select the correct icon on the desktop, we had two icons "In office" and "Out of office" then the correct profile was loaded. The "out of office" would look on the laptop for programs etc, Yes had a slightly different set of menu's. The profile choice is in the ICON properties.

 

 

Hi BIGAL,

 

First off, thank you for sharing your perspective on how the community and your clients are handling the "cloud" today. It’s really insightful to hear where the landscape actually stands from someone with your experience.

 

You’re spot-on that most people currently just map AutoCAD Support Paths to a static cloud drive folder. And that "In office" / "Out of office" dual-icon setup you mentioned? That is a brilliant piece of classic IT problem-solving! It perfectly captures the exact nightmare CAD Managers have dealt with for years when engineers take laptops to construction sites.

 

Analyzing those classic IT workarounds highlights that the core deployment challenges in CAD haven't changed, but modern architectures give us new ways to tackle them. At their core, almost all traditional methods—whether passing local ZIPs or mapping static cloud drives—rely on static distribution. Once a file leaves the source, its connection is severed, inevitably leading to version fragmentation across the firm. This is exactly why we designed VedaCAD to provide dynamic lifecycle management through a "Cloud-Managed Local Sandbox", rather than just live cloud mapping.

 

From an engineering standpoint, here is how we structured the technical measures to handle those specific scenarios:

 

1. Solving the offline field scenario Mapping directly to a cloud drive introduces fragility—if the internet drops, CAD freezes. To prevent this, everything in our architecture physically runs from a local sandbox cache on the C drive. The client simply pings the server with a lightweight heartbeat. If an engineer opens their laptop on a site with zero Wi-Fi, the LISP kernel silently transitions into Offline Mode. They keep drawing seamlessly using their local cache until the configured offline grace period expires. No need for separate desktop icons.
2. Managing binary updates and file locks When a developer patches a .vlx or .dll, expecting users to manually download and replace ZIPs leads to version fragmentation. We shifted this to a heartbeat-driven sync. When the server detects a version drift, the update is pulled into the sandbox. Depending on the workspace policy (Manual, Auto, or Enforced), the user either clicks to approve it, or the engine hot-swaps it silently in the background. To bypass Windows file locks on running binaries, the engine utilizes a backend .bak renaming trick to perform the in-place replacement without crashing CAD.
3. Resolving subcontractor environment consistency How do we ensure that all subcontractors perfectly align with the drafting standards set by the general contractor, even down to the absolute uniformity of a single linetype color? We tackled this by building isolated containment fields we call "Project Arks". Instead of emailing ZIP files of CAD standards, a General Contractor can package their absolute drafting environment and issue a time-limited "Visa". When a subcontractor mounts it, their CAD temporarily mirrors the GC's standard. Crucially, if the GC updates a .ctb or other environment configuration files mid-project, the subcontractors pull the latest standard on their next heartbeat or upon manual sync, allowing the GC to monitor exactly which external terminals are lagging on outdated standards.
4. Asset revocation and self-healing If a subcontractor's Visa expires, or an internal employee's device is unbound, the system relies on a zero-trust model. Upon the next ping, the engine executes a remote kill-switch, physically shredding the proprietary CAD assets from the local cache. Conversely, if a user accidentally deletes a cached plugin, the LISP reactor detects the loss via a native (findfile) check and instantly auto-fetches the replica from the cloud, ensuring the execution chain never breaks.

 

It’s always a pleasure geeking out over deployment architectures with veterans. Thanks again for the great discussion!

 

Cheers, Vico

Edited 53 minutes ago by VicoWang