Category Archives: Development

The BLADE video watchlist

I did my third and final (for now) BricsCAD Unplugged webcast about BLADE last Wednesday. Here’s the video:

Before I dig into DCL, I start with a brief description of an absolutely brilliant feature that was added to BLADE in V19. If you code in LISP, you’ll love this feature.

Then I move on to some ancient history. Did you know that we can thank the far-sightedness of some slightly renegade Autodesk OS/2 developers in the early 1990s for the dialog boxes we use today? Did you know that you could program dialog boxes for AutoCAD for Mac in 1993 but you can’t today? Can you spot the items of interest in the background?

The rest of the video is dedicated to describing DCL programming and debugging, and I explain how BLADE is the best tool for that job using examples.

If you want to watch all three of the BLADE videos in a row (that’s 1 hour 49 minutes of viewing), Matt Olding has created a YouTube playlist for this series.

It has been an absolute pleasure working with the Bricsys people in putting this series together. Torsten Moses has informed me about yet another bunch of enhancements that are coming very soon to BLADE, so maybe you haven’t heard the last from me on this subject on BricsCAD Unplugged.

More BLADE videos

As mentioned previously, In December I made a guest appearance on the BricsCAD Unplugged webcast series to discuss the LISP development environment, BLADE (YouTube link).

I made another appearance last week describing debugging using BLADE (YouTube link):

If you’re dealing with LISP code for AutoCAD and/or BricsCAD, you really should be doing it in BLADE. It’s the best development environment for AutoLISP/Visual LISP that you’re ever going to get.

I have another appearance scheduled for later today (13 February) in which among other LISPy things, I will be discussing using BLADE for DCL programming. Again, even if you’re AutoCAD-only, I believe this is worth a watch. BLADE is better for DCL programming, too.

Even if you’re AutoCAD-only and not a programmer, you might find my brief ancient history lesson of interest. Did you know that BricsCAD for Mac users can thank a far-sighted early 90s Autodesk OS/2 team for the dialog boxes they use today?

The BricsCAD Unplugged webcast broadcasts run on the Bricsys Facebook page and are then quickly transferred to YouTube. Today’s session will start at about UTC 14:15 (2:15 PM) on Wednesday, 13 February 2019 (click here for your local time)

Addendum – Why every AutoCAD CAD Manager should have a copy of BricsCAD – part 1, fixing drawings

This post is an addendum to a post from June, Why every AutoCAD CAD Manager should have a copy of BricsCAD – part 1, fixing drawings. This post provides new information about useful functionality added in V19 of BricsCAD that is useful for any CAD Manager or power user who ever has problem DWG files to deal with. Yes, even if your site is still purely AutoCAD-based.

In this post I’ll describe the (inspector) LISP function. This was added in the V18 cycle but was significantly enhanced in V19. It’s probably the most useful LISP function you’ve never heard of.

Although it’s LISP, that doesn’t mean you have to be a programmer to benefit from it. If you’re a non-programming CAD Manager or power user, you can use it to work out what’s going on within any DWG you’re having problems with. You can use it to discover information about objects in the drawing; not just conventional entities, but also blocks, tables, dictionaries and so on. It even works with custom data.

I gave a brief demonstration of (inspector) in the last BricsCAD Unplugged episode about BLADE. However, you don’t need to use BLADE; just enter (inspector) at the command prompt, select an object and you’ll be presented with a dialog like this:

These dialogs are modeless, and you can have as many displayed as you like; you’re not limited to one. This dialog displays the same data in three different ways. At the top, it’s shown in traditional LISP assoc form, and by playing with the Expand controls you can vary the way in which this is pretty-printed. The bottom left pane shows the data in DXF form, which is probably easiest to read if you’re a non-programmer. If you’re more of an ActiveX person or you prefer to see the properties described with words rather than numbers, you’ll prefer the display on the bottom right, which shows the COM properties for the object.

If you want to select another object to inspect without calling (inspector) again, just use the [ > > ] button.

The grayed-out lines indicate data that is considered read-only. It’s important to note that this doesn’t mean it’s impossible to change the data, merely that the ways in which that data can be changed within a program is restricted. Generally, it means you can’t change the ActiveX properties directly, but there are various other means that can be employed in many cases.

The lists are somewhat interactive; double-click on an entity name and you’ll be given another inspector window for that entity. You can burrow down through the drawing database in this way, looking for the source of your mystery DWG problem. If you’re using it while programming, you can use it to work out what set of circumstances is causing your code to trip up in certain drawings.

The (inspector) function has an optional argument, and what it will accept is very flexible. If you pass an entity name to it, you will get the data for that entity displayed. The same principle applies for various ActiveX objects: pass it a layer table object and the appropriate data will be displayed.

Direct access is provided to various useful things from within BLADE using the pull-down menu Lisp+DCL > Browse DWG Database:

If you pick Browse Text Styles, you’ll see something like this:

Double-click on one of the text style items in the left pane and you will get this:

As you can see, this is very handy for tracking down issues both while programming and when diagnosing DWG problems.

Finally, I should note that there is potential for the inspector to provide even more power in future. Bricsys LISP guru Torsten Moses is investigating the possibility of allowing the inspector to modify data, not just inspect it. There’s potential danger there, but if Torsten can make that work safely then that would be another invaluable tool for any DWG-based CAD Manager.

As I stated in my original post, it’s definitely worth a CAD Manager’s while to do the quick download and install of an evaluation BricsCAD. My experience in dealing with Bricsys is that requests for extensions for evaluation purposes are usually accepted, so you probably won’t have to give up your valuable tool as soon as your 30 days are up.

Video – who is that masked man?

Last night I made another guest appearance on the BricsCAD Unplugged webcast series. This time I was discussing the LISP development environment, BLADE. Here’s the video:

Bonus points will be awarded for identifying three items of interest in the background. No, not counting my dog Sunday asleep at lower left.

Despite going way over time, there was still nowhere near enough opportunity to describe the full LISPy awesomeness that BLADE represents. I am therefore scheduled to return for another two or three episodes beginning in February. In those, I’ll be doing more of a step-by-step demonstration rather than the overview and V19 new feature description I did in this episode. If you have any particular requests for what you want covered, please comment on this post.

I also showed how the tools in BLADE (e.g. the (inspector) function) are still worth having for any DWG-based CAD Manager or power user, even if you’re not a full-on LISP programmer. If you have to work out what’s going on with dodgy DWG files, you’ll want to have (inspector) in your set of tools.

The BricsCAD Unplugged webcast broadcasts run on the Bricsys Facebook page and are then quickly transferred to YouTube. This was the last episode for 2018 because of Christmas and New Year.

Wielding BLADE on BricsCAD Unplugged

In September I was the special guest on the BricsCAD Unplugged episode BricsCAD Unplugged – Steve Johnson 5 surprises moving to BricsCAD. Next Wednesday I will return, this time to wield BLADE, the best thing to happen to CAD LISP in nearly 20 years. I’ll be introducing it and demonstrating a few things, including the new features that came with V19.

These live broadcasts are run on the Bricsys Facebook page and are then quickly transferred to YouTube. This broadcast will start at UTC 15:00 (3 PM) on Wednesday, 19 December 2018. Here’s that time in a few handy time zones:

Location Zone Time
San Francisco PST 07:00
Minneapolis CST 09:00
New York EST 10:00
London GMT 15:00
Brussels CET 16:00
Moscow MSK 18:00
Mumbai IST 20:30
Perth AWST 23:00

DOSLib goes open source

What’s DOSLib?

DOSLib is a free library of LISP functions that adds a lot of functionality to AutoLISP/Visual LISP/BricsCAD LISP. It makes a lot of programming tasks a lot easier, because instead of writing a bunch of code to do tricky stuff, you can just load the library and call a ready-made (dos_xxx) function. There are hundreds of functions that cover the following areas (taken from the McNeel Wiki):

  • Drives – Check for drives, change between drives, and check available disk space.
  • Paths – Manipulate path specifications.
  • Folders – Create, rename, remove, select, and change folders. Return special operating system folders.
  • Files – Copy, delete, move, rename, and select files; get directory listings, search and find multiple instances of files, and change file attributes.
  • Print – Get and set default printers, and spool print files.
  • Configuration – Manipulate Windows-style initialization (INI) files, and access the Windows Registry.
  • Processes – Run operating system commands or other programs.
  • Interface – Get strings, integers, reals, and lists from the user. Display Windows message boxes, progress meters, and splash screens.
  • Strings – Tokenize strings, extract characters, find characters, insert, remove, and replace characters, and trim characters.
  • Math – Trigonometric calculations, vector manipulation, statistical analysis, and more.
  • CAD – Save all and close all open files. Preview drawings and list xrefs.
  • System – Get system information, sort lists, change the system date and time, manipulate the keyboard, and play sounds.

Why would a CAD LISP programmer use it?

There are many DOSLib functions that would be difficult to write purely in LISP and quite a few that would be impossible. So for those people who want to code for AutoCAD and BricsCAD without the bother of learning ARX/BRX and dealing with the associated compiler requirements, DOSLib has been a godsend. It’s worth noting that some of the DOSLib functions have been added to BricsCAD’s LISP engine, so depending on the function you use, you may not even need to load the DOSLib library.

Do impressive-looking stuff without writing much code. You might call it being lazy. I call it being efficient.

A history of dependability

DOSLib has been around for many years. It is currently supported on AutoCAD 2013 and later and BricsCAD Pro V13 and later, but earlier versions have supported AutoCAD releases dating back to 1992! Dale Fugier at Robert McNeel and Associates has been providing outstanding service in developing DOSLib and keeping it up to date. For nothing!

So developers have been able to take advantage of the DOSLib functionality all that time, and Dale has always come up with the goods in terms of updates to work on new releases of AutoCAD and BricsCAD. However, you may have had a nagging doubt about writing code that relies on a third party, or as a CAD Manager relying on such code, no matter how rock-solid reliable that party has proven in the past.

That nagging doubt can now be put to bed, because Dale has announced that DOSLib has been made open source under the very open and simple MIT license. The GitHub DOSLib page has the source, with compilation and other relevant information.

All good news

Dale has also stated that he intends to continue to provide compiled binaries for the foreseeable future, so don’t worry about having to mess with compilers. Even if a meteor happens to land on McNeel headquarters, it’s a pretty safe bet that somebody in the AutoCAD/BricsCAD development community will, after a suitable period of mourning, step forward to compile the code for new AutoCAD/BricsCAD releases when required.

The availability of the source code also opens the door for DWG-based applications (other than BricsCAD) to attempt to provide a higher level of LISP compatibility, to the extent of supporting (dos_xxx) function calls. That means you, the CAD LISP programmer, will have a wider potential audience for any code you write that uses DOSLib functions.

Finally, if you’re an ARX/BRX developer who wants to do something similar to something in a DOSLib function, you now have some handy sample code.

So this is all good news, and yet another example of Dale and McNeel doing the right thing by the CAD community.

Video – Steve on BricsCAD Unplugged

Following on from Lynn Allen and Robert Green’s guest appearances on the BricsCAD Unplugged webcast a couple of weeks ago, this time it was my turn.

Last night (my time) I was the special guest on the episode BricsCAD Unplugged – Steve Johnson 5 surprises moving to BricsCAD. I’m introduced at 2:12 and appear at 3:30. Here’s the full video:

In this week’s episode, you’ll witness:

  • Me discussing the five biggest things that pleasantly surprised me about BricsCAD. (I have more than five, but time was limited).
  • Don Strimbu bribing me with drinks containers.
  • An actual printed copy of Cadalyst magazine from 1995, complete with my old column Bug Watch (1995-2008).
  • The excellent euphemism, “You’re generally pretty conservative in terms of your praise.”
  • Don throwing me a curveball by introducing my points out of order!
  • The announcement that I’ll be at Bricsys 2018 in London and possibly participating in the BLADE session.
  • Me saying, “No. I’m wrong.”
  • Me drinking a glass of wine (parental guidance advised – alcohol consumption depicted). If you care, it’s a Shiraz (that’s Syrah if you’re American) from South Australia’s Limestone Coast region.
  • Total lack of coordination from everyone in raising our drinks at the end.

Thank you to the Bricsys crew for the invitation, it was a blast! If you ever want me on again, I’ll be happy to oblige.

For future reference, these live broadcasts run on the Bricsys Facebook page and are then quickly transferred to YouTube.

Mac users rejoice – at long last, a LISP IDE comes to OS X

CAD’s best LISP development environment has come to the best “AutoCAD for Mac”. It should come as no surprise to anyone that this has occurred without Autodesk’s involvement.

What’s happened?

With the release of BricsCAD (Mac) V18.2 (currently V18.2.23-1 to be precise), BLADE (BricsCAD’s much-superior equivalent to VLIDE) has been added to BricsCAD

See here for the release notes and here to download. Make sure you select the Mac version:

Significance

This is pretty significant for anybody serious about using DWG-based CAD on the Mac. AutoCAD without LISP is hardly worthy of the name, which is why I’ve never been keen on AutoCAD LT from the moment LISP was yanked out of it just before release in the early 90s. There has never been an integrated development environment for AutoCAD for Mac (either in the first iteration in the 1990s or the second attempt in the 2010s) and I think I can safely predict that there’s never going to be one. I expect AutoCAD for Mac’s LISP to remain forever in 1990 mode.

Compatibility

One problem a small number of users may face when developing for Mac with BLADE is that of downward compatibility. In case you’re wondering, BricsCAD (Mac) to AutoCAD for Mac is very much a downward direction, particularly in the area of LISP. The LISP in AutoCAD for Mac is famously half-baked with large portions of functionality missing, including no ability to control dialog boxes. BricsCAD (Mac)’s LISP is very much more capable, so while compatibility between AutoCAD for Windows and BricsCAD (Mac) is strong, you can’t say the same for LISP compatibility between AutoCAD for Windows and AutoCAD for Mac.

Half of the stuff you write for AutoCAD in Windows is just going to fail when you try to run it in AutoCAD for Mac. Much more of it is going to work in BricsCAD (Mac). While you can now write, debug and run your LISP code efficiently in BricsCAD (Mac) and it’s practically guaranteed to run just fine in AutoCAD and BricsCAD for Windows, it will be very easy to write stuff in BricsCAD (Mac) that doesn’t work in AutoCAD for Mac. Of course, the same downward compatibility problem applies to writing stuff in AutoCAD for Windows using VLIDE.

If you’ve moved on completely from AutoCAD for Mac to BricsCAD (Mac), that’s not going to be a problem. Bircsys building a notably better product that’s significantly more compatible with the main game is not something anybody could reasonably condemn. However, but it’s something to bear in mind if you are hoping to write code that runs on both AutoCAD and BricsCAD for Mac.

Summary

That caveat aside, it’s all good news for Mac CAD users. You already had a product available that would run a much higher percentage of the huge library of LISP out there than AutoCAD for Mac would. For the first time in history, you now also have access to a professional LISP development tool. Lucky for you, it’s the best such tool on the market.

Why every AutoCAD CAD Manager should have a copy of BricsCAD – part 6, future proofing

This is the sixth and final post in this series where I explain why this statement holds true:

As a CAD Manager looking after AutoCAD users, or a power user looking after yourself, it’s worth your while to have a copy of BricsCAD handy.

This post explains why adding a copy of BricsCAD to your stable of AutoCAD licenses is a good thing for your future and that of your company.

A CAD Management thing I did a few years ago was to examine the options for replacing AutoCAD and other Autodesk products. I was an AutoCAD loyalist (albeit a somewhat critical one) with over a quarter of a century invested in it. I was looking after the deeply entrenched and very heavily customised CAD environment of a major public utility company that had been using AutoCAD as its primary CAD system since the late 1980s. Hundreds of custom commands were in place and providing priceless productivity benefits. Hundreds of thousands of DWG files were on file, with thousands more coming through every month. The inertia behind AutoCAD was very, very strong. Looking outside the cage was a pretty radical step to take. What led me to that point?

  • Autodesk business policy. Autodesk has become increasingly anti-customer over the years in ways that will be familiar to all readers of this blog. I won’t rehash them here. This leads to…
  • Increasing costs. Autodesk software is expensive and getting more so. Autodesk has made no secret of its intention to move to an all-subscription (rental) model. This is an attempt to treble the ongoing income Autodesk receives, in return for doing as little as possible. Which leads to…
  • Lack of progress. It had become clear that the days of AutoCAD seriously improving from release to release were over, never to return. This isn’t because there is no room for improvement, it’s because Autodesk doesn’t want to improve AutoCAD. AutoCAD won’t be permitted to become too capable because that would just eat into sales of Autodesk’s other products. You’re not going to see 3D parametrics or sheet metal capabilities in AutoCAD: buy Inventor instead. You’re not going to see BIM capability: buy Revit. Beyond the internal competition issue, some years ago, Autodesk leadership lost interest in what it perceived to be an old-fashioned dead-end product. The income from AutoCAD customers is being diverted to fund purchase and/or development of more fashionable and interesting products.
  • Frustration with Autodesk’s Beta program. The goings-on within the Autodesk Beta program must remain private, so what I can say here is limited. I can say that I spent many years contributing large numbers of hours to that program in order to attempt to improve the product. As time went on, the positive results that emerged from that effort decreased; that much is no secret because it is apparent in the product. I felt I was fighting against Autodesk to try to improve the product, and losing. There were a few final incidents that persuaded me to stop bashing my head against that particular wall. I wasn’t the only one. I stuck it out for years longer than many very valuable people who had already given up before me.
  • Proxy server issues. Over the years, Autodesk’s habit of attempting to do sneaky things to access the Internet had caused a variety of problems in a secure proxy server environment. This caused several things not to work, and harmed performance severely in some places. As Autodesk’s developers turned over, things that worked in one release would not work in the next. Attempts to get this addressed as a support issue would result in the environment being blamed. These problems increased over the years as Autodesk threw in more and more connectivity-requiring features. There was a non-zero and ever-increasing possibility that one day, Autodesk would screw things up altogether and leave us with non-functioning software. That has already happened for some people, and although the stoppage has generally been temporary, it is important to have redundancy.
  • Poor performance. AutoCAD has been getting bigger and slower. Downloads are huge and Autodesk does its best to make them as difficult as possible. Installations take an age, as do uninstallations. Startup times are terrible and getting worse. My users were complaining – a lot – and there wasn’t much I could do about it.

That’s what moved me to take a very, very serious look at alternatives. Your motives may differ. Just the desire to have a Plan B in case of disaster might be enough.

If you don’t feel moved to investigate, you may eventually be faced with no option. Sooner or later, the person who holds the purse strings at your company may point to this year’s much bigger Autodesk invoice and ask, “What are we getting for this? How can we reduce our costs?” When that happens, you don’t want to be scrabbling round for answers before that invoice needs to be paid. Look into the options in advance. Are you really wedded to AutoCAD or are you actually tied to DWG?

Days of Future Past

Here’s my suggestion. Examine the available alternatives to AutoCAD and the other Autodesk products you use. Do it sooner rather than later so you get the chance to determine the answers to non-trivial questions like these:

  • Capability. Does the alternative product do everything that AutoCAD does, that your users need it to do? Does it do other stuff that AutoCAD doesn’t that you might find useful? What’s the performance like? How does it work on the hardware you have? Does it have user interface elements that don’t just look good but work productively in practice?
  • Compatibility. You will almost certainly demand extremely good DWG compatibility, but this question goes well beyond that. Will your LISP work? How about DCL? ActiveX support? DOSLib? Other programming languages? Can you carry over your customisation files? Can you make the interface look the same? If you have custom toolbars, or ribbon, or even image menus, do they carry across? Can your users carry across their skills without downtime, extensive training and a productivity hit? Can AutoCAD and the potential replacement coexist without issues? Can you use a common set of custom support files pointed at by both products? Will it work well on your hardware?
  • Add-ons. If you’re using third party products on top of AutoCAD, or if you’re using an AutoCAD-based vertical, is that product or an equivalent available? Does it work well? What do the objects they create look like in plain AutoCAD? Can you round-trip through AutoCAD and back and retain your intelligence? You’re probably going to have to test this with evaluation software and your own data.
  • Licensing options. Is perpetual licensing available? Can you stick on a release for a few years and still purchase upgrades later? Has the company committed to providing you with licensing options or has it made noises about going all-rental? Is network licensing available? Does it coexist problem-free with Autodesk’s network licensing software?
  • Costs. Compare the likely costs for all your options over several years. You’re going to have to make some assumptions. It can be difficult to work out what they should be.
  • Track record. Has the company been around for a while? What reputation does it have? Does it treat its customers with respect? How good is the support?
  • Future prospects. Is the company likely to be around long-term? Is it actively developing the product you’re interested in? Is it innovating? Is it merely following AutoCAD at a distance or charging ahead? Is the product going to be limited by Autodesk-like internal competition?

I went through all of these questions and settled on BricsCAD as the best option in my company’s case. In fact, several aspects made it really the only viable option. The product impressed me with high performance, capabilities well beyond AutoCAD in several important areas, a very high degree of compatibility (particularly LISP but also other customisation files), the availability of perpetual licensing and much lower ongoing costs. The company impressed me with its honesty and attitude toward customers.

Most of all, I was won over because I could see that the product had a future. Subsequent improvements have only strengthened that view.

Obviously, you need to make your own judgement based on your own circumstances. I would suggest looking at all the options, including sticking with AutoCAD permanently, with or without subscription or maintenance. Maybe you can use my investigations as a starting point, but I encourage you to start investigating now rather than when you’re under time pressure and don’t have time to do a thorough job.

It will cost you a few minutes to download and install of an evaluation BricsCAD and start preparing for the possibility of a different future. Maybe it won’t turn out to be part of your company’s future, but it could still be part of your future.

Options are good. Learning is good. Best case scenario, your knowledge is going to save your company money and improve its productivity, and you will end up smelling of roses. Worst case scenario, you’re going to spend some very justifiable time doing something new, different and interesting. I recommend it.

Other posts in the Why every AutoCAD CAD Manager should have a copy of BricsCAD series:

Part 1, fixing drawings
Part 2, 3D operations
Part 3, parts on demand
Part 4, efficiency
Part 5, LISP

Why every AutoCAD CAD Manager should have a copy of BricsCAD – part 5, LISP

This is the fifth post in this series where I explain why this statement holds true:

As a CAD Manager looking after AutoCAD users, or a power user looking after yourself, it’s worth your while to have a copy of BricsCAD handy.

This post is about BricsCAD being better than AutoCAD at the one thing that made AutoCAD win the race against its competitors back in the 80s – LISP. That is, AutoLISP (added fully to AutoCAD in Version 2.18) and Visual LISP (fully integrated with AutoCAD 2000).

If you’re a good AutoCAD CAD Manager, you’ll already know the reasons LISP is an extremely important tool, so I won’t cover them here. I may explain those reasons in a later post, but that would distract us from the main point. Why is having a copy of BricsCAD useful to a CAD Manager?

  • BLADE. I’ve covered the BricsCAD LISP Advanced Development Environment in various posts already, and I intend to go into greater detail in future posts. There are enough advantages over VLIDE to warrant an entire series of posts. This is simply the biggest advance for CAD LISP in 20 years; if you’re doing any reasonably complex development in LISP and you’re not BLADE, you’re wasting time and money.
  • Performance. Because BricsCAD’s LISP engine is much more modern than AutoCAD’s, the performance is much greater. In my experience, it’s about three times as fast. Some function calls are as much as 30 times as fast. If you have a user who’s complaining that your routine is taking an age to process in AutoCAD, try it in BricsCAD instead. I once saved a user half an hour in processing time for one polyline by using BricsCAD. Another aspect that will benefit you when programming and testing is BricsCAD’s generally superior performance. Got nothing running and want to get programming in the next 5 seconds? Fire up BricsCAD. Want to do a complex process on a big drawing that makes AutoCAD run out of RAM? Try it in BricsCAD.
  • Licensing. While you’re developing in BricsCAD, you’re not using up an expensive AutoCAD license. You’re using a cheaper (or even free, while you’re evaluating it) BricsCAD license. Also, it’s a perpetual license so if you ever stop paying, you can keep developing as long as you like. Oh, and it’s not going to flake out on you on those days where Autodesk’s subscription licensing server has a meltdown.
  • Extra functionality. BricsCAD’s LISP has the AutoLISP and Visual LISP functions and then some. Some of the DOSLib functions are available without even needing DOSLib, but if you need the full set of DOSLib functions they can be loaded, as per AutoCAD. A range of extended functions are available with the vle- prefix, and the LISP Developer Support Package documents these and provides the source code so you can also use them in AutoCAD.
  • Platform independence. AutoCAD for Mac has severely restricted LISP capabilities, making it unsuitable for use in a professional, efficient custom environment. BricsCAD for Mac and BricsCAD for Linux both provide practically identical functionality to the Windows version. Yes, BricsCAD for Mac really is significantly more AutoCAD-compatible than AutoCAD for Mac.

I do my LISP development in BricsCAD these days, and can attest that it’s well worth the investment in time to get the hang of BLADE.

It will cost you a few minutes to download and install of an evaluation BricsCAD and check out the LISP situation for yourself.

Edit: it’s not just LISP. See James Maeding’s comment below about .NET, too.

Steve’s BLADE presentation at the BricsCAD New Zealand and Australia Roadshow

Sofoco (Australia) and CAD Concepts (New Zealand) recently ran a series of seminars throughout Australasia demonstrating BricsCAD. I attended the last of these in Brisbane on April 19 and gave a presentation about BricsCAD’s LISP, with reference to AutoCAD compatibility and the tools available to CAD Managers and developers, including BLADE. The talk was aimed at anybody who is writing or maintaining LISP code for AutoCAD or BricsCAD.

I had the just-before-lunch slot, which is never desirable for a presenter. People are dozing off and/or bursting to go to the toilet, and time adjustments have to be made if earlier presentations run over. I started 10 minutes late and therefore had to remove the demonstration part of the presentation on the fly, but I had planned to allow for that eventuality. It’s been a while since I have presented like this before an audience so I was a bit rusty and it wasn’t as free-flowing as I would have liked. Too many ‘erms’!

Steve’s invisible accordion is impressively large

I did manage to keep the whole audience in their seats until the end, though, so that’s something. Maybe the fact that I was waving a sword around had something to do with it.

Here’s my video, which is 21 minutes long. The sound is a bit muffled and my accent is Australian, so you might want to turn on subtitles using the CC option in the YouTube player.

Disclosure: the organisers covered part of my expenses.

Steve at the BricsCAD New Zealand and Australia Roadshow

Sofoco (Australia) and CAD Concepts (New Zealand) are currently running a series of seminars throughout Australasia demonstrating BricsCAD.

Here are the dates and locations:

Auckland – 9 April 2018, Jet Park Hotel and Conference Centre
Christchurch – 11 April 2018, Christchurch Community House
Melbourne – 17 April 2018, Airport Motel and Convention Centre
Sydney – 18 April 2018, Stamford Plaza Sydney Airport
Brisbane – 19 April 2018, Royal on the Park

Each seminar is in two parts. The morning session is for leaders and decision makers and the the afternoon is less structured and goes into more details, with informal discussions, questions and answers and one-on-one sessions. There will be many short presentations from various presenters to demonstrate the different things that BricsCAD is capable of, with or without third party add-ons.

I’ll be travelling to the Brisbane show. I’ll be there for the whole day but will be doing a brief presentation about BricsCAD’s LISP, with reference to AutoCAD compatibility and the tools available to CAD Managers and developers, including BLADE.

I have experience not only in developing using LISP in AutoCAD and BricsCAD, but also in transitioning from one to the other in a comprehensively modified custom environment. I hope to be of some assistance to CAD Managers and users who are considering such a move. I believe there are still seats available.

Disclosure: the organisers will be covering part of my expenses.

CAD Panacea tip – startup files in BricsCAD

One of the things that might initially baffle a CAD Manager or power user when investigating switching from AutoCAD to BricsCAD is how to set up the startup routines. Head over to CAD Panacea for R.K. McSwain’s concise, handy description of how to do it.

Due to BricsCAD’s high level of compatibility, you can maintain a common folder or set of folders containing LISP and other custom files for both applications. That way, you don’t need to do double maintenance during the transition period. I’ve done this successfully in a highly complex custom environment. Some code and other adjustments were required in places, but all but a handful of my hundreds of AutoCAD LISP files worked as-is in BricsCAD with zero effort.

Having added your AutoCAD custom folder(s) to BricsCAD’s search path, I suggest you make a common startup LISP file (e.g. rename your old acaddoc.lsp to something like CADStartupDoc.lsp) and have tiny stub startup LISP files for each application (acaddoc.lsp and on_doc_load.lsp) that each loads the common startup file.

acaddoc.lsp contents:
(load "CADStartupDoc")

on_doc_load.lsp contents:
(load "CADStartupDoc")

You can add error checking and messaging if you like, but if you have control of your environment you probably won’t even need that. If you find you do need any application-specific code, you can just add it or load it from the acaddoc.lsp or on_doc_load.lsp stubs as appropriate.

BLADE – putting things back to “normal”

Disclaimer: I’m making money using BLADE. I’m using it on a paying project right now (well, not while I’m typing this, but you get the idea). I’m developing a routine to automate a massively repetitive task for one of my AutoCAD-using clients, and I’m developing it in BricsCAD and BLADE rather than AutoCAD and VLIDE.

I can simply develop faster in the more modern environment, and BricsCAD’s significantly quicker start-up time helps with that. So does the fact that the routine runs several times faster in BricsCAD, making testing the large data sets much more efficient. I’m getting paid on results and not by the hour, so using BLADE is putting cash straight into my pocket while giving me more time to walk my dog.

Using BLADE in production, I’m discovering a few bugs, quirks and things I don’t like. That’s totally understandable with a new feature of this level of complexity and functionality. Where I think it makes sense, I’m submitting problem reports or feature requests to Bricsys. I’m sure Bricsys already has a bunch of these from other developers, so they’ll be very busy for a while. From past experience, I know my reports will be taken seriously and acted on appropriately in a timely manner, if it’s feasible to do so. Your LISP IDE feedback won’t be ignored for decades by Bricsys.

One of the things Torsten Moses mentioned to me that didn’t make it into the published interview was that many developers are very conservative. There’s some truth in that. I’m missing certain keystrokes, for example: 1978-era WordStar Ctrl-Y to delete a line, anyone? It’s a reasonable expectation that as more VLIDE users migrate to BLADE, many requests will come in for VLIDE-like things. I’m told that some of these things will be provided in coming months.

In the meantime, there are things we conservative developers can do to make ourselves feel more at home. One of these is to configure the editor appearance. Here’s the VLIDE editor:

Here’s the BLADE equivalent:

One of the great things about BLADE is how configurable it is, and I know Torsten’s working right now on making it even more so. Configurations are stored in the Registry in a version-independent location (HKCU\Software\Bricsys\BricsCAD\VLispDbgEditor). These can be exported and imported directly or via BLADE, so multiple complete setups and configurations can be managed.

In this post, I’m going to be going through the process of configuring BLADE’s editor appearance to make it look more like VLIDE. I’m not suggesting that’s necessary or even a good idea in most cases, but if you really want to do it, here’s how.

Note: before you do all this manually, please note that at the end of this post I will provide a configuration file that will do it for you.

  1. Start up BricsCAD V18.2 or later and start BLADE using either the BLADE or VLIDE command.
  2. Open a LISP file in BLADE so you can check the effects of the changes we’re going to make.
  3. Use Preferences > Show preference dialog…
  4. In the Preferences & Settings dialog, pick the Styles tab and the Lexer Styles sub-tab.
  5. I’m perfectly happy with Courier New 10, but if you want the VLIDE look, change 1 – Default text to Fixedsys 11.
  6. Click next to 3 – Comment, turn on the Background color toggle and change the Back Color to mid-grey (192,192,192) and Fore Color to dark magenta (128,0,128). You’ll need to specify that RGB value in the lower right corner and use Add to Custom Colors to do this.
  7. Click next to 5 – String and change the Fore Color to magenta (255,0,255).
  8. Click next to 7 – Operator and change the Fore Color to red (255,0,0).
  9. The 8 – Keyword 1 setting should already be blue as in VLIDE. If you want system constants such as T, nil and pi to also be that shade of blue then change 9 – Keyword 2 accordingly. Personally, I prefer a different shade so they stand out. Mid-dark cyan (0,128,192) works well.
  10. I like the pale grey background in BLADE that helps identify the current line. If you don’t, click next to 8 – Caret colour and turn off the Background color toggle.
  11. Switch to the Editor Colors sub-tab, click next to 5 – Selection colour and change the Back Color to a custom mid-blue (0,120,215).
  12. While you’re in the Editor Colors sub-tab, there are a few other non-VLIDE things you can play with. 1 – Brace hilight and 2 – Brace mismatch are dynamically applied to matching and non-matching parentheses respectively. I like my Brace hilight setting to be plum and bold (turn on the Attributes toggle to enable this):

I like my non-matching setting to be white on red (the inverse of a normal parenthesis so it shows up):

Changing all that should give you something that looks like this. Familiar enough?
There are several things in the above image that might be unfamiliar but which I suggest you leave turned on because they’re useful. If you really insist, here are the locations for these settings in the Preferences & Settings dialog:

  1. Line numbers  – View > Margins, Show line number margin
  2. Marker margin – View > Margins, Show marker margin. If this is turned off, bookmarks show up using the settings under Styles > Editor Colors > 13 – Bookmark marker.
  3. Edge marker (that vertical line on the right indicating 80 character width) – View > Edge marker > Type, No background.
  4. Indentation guides (those vertical lines that show you what your code is lining up with) – Tabs and EOL > Indentation, Show indentation guides.
  5. Code folding margin (the margin on the left that allows you to collapse functions, etc. – Folding and Wrapping > Show code folding margin.

Unlike VLIDE, the default in BLADE is to use spaces for indentation, not tabs. As I don’t know of any LISP developer who uses tabs except by accident, this is a much more sensible default. But if you really want to use tabs, turn it on using Preferences > Use tabs and set the width to the VLIDE default of 8 in Preferences > Set tab width.

If you’ve left opening parentheses on previous lines and have indented the following code as usual, then as you go on to finish off the code with closing parentheses, in BLADE a single backspace will take you back your indent width (2 spaces by default) rather than a single space as in VLIDE. If your coding finger can’t get used to this keystroke-saving feature, you can turn this off with Preferences > Backspace unindents.

Having done all that, and having arranged the rest of the interface to your needs (overall window size, pane and field widths, etc.), make sure you save it! It’s as simple as Preferences > Save preferences, but it’s not done automatically. If you want to keep a safe copy of your settings, you can do so with Preferences > Save preferences to file. This simply exports the relevant part of the registry to a .reg file of your choice. This is a text file you can hack about with at your leisure (using BLADE if you like!), and you can even make files that represent subsets of your preferences.

For example, I’ve removed all but the style settings from a .reg file I exported. I’ve uploaded it renamed as a .txt file because .reg files are considered dangerous by browsers, etc.

If you want to use this to give BLADE that old familiar VLIDE look, here are the steps.

  1. Download SteveVLIDE-likeBLADEStyleSettings.reg.txt.
  2. Rename the file to remove the .txt extension so it becomes SteveVLIDE-likeBLADEStyleSettings.reg.
  3. In BLADE, use Preferences > Load Config from File
  4. Close BLADE and BricsCAD.
  5. Restart BricsCAD and BLADE.

That should do it. Happy BLADEwork!

Interviewing the creator of BLADE – CAD’s best LISP IDE – part 2

This post continues my interview with Torsten Moses about BLADE, the new LISP IDE that arrived with BricsCAD V18.2. See here for post 1.

Steve: I’ve noted before that BricsCAD execution of AutoLISP and Visual LISP is several times faster than AutoCAD’s. How does the new technology affect that performance?

Torsten: All the new BLADE-related stuff doesn’t really affect normal LISP execution outside the IDE and debugger. The connection is made by a few callbacks, which take zero time in normal processing. Therefore there is also no chance of breaking things. The BLADE implementation is very safe, and performance remains high for normal usage. For the debugger and the synchronization, it is all home-brewed stuff, optimized for best performance even when debugging, and minimum system and LISP memory usage.

In the course of implementing the debugger and internal versus external synchronization, I also removed most emulations and implemented that as core OpenLisp functionality. That has the side-effect that the (repeat), (foreach) and (vlax-for) functions now run about five times faster at the loop construction. So rather than slowing things down, creating BLADE has actually speeded things up!

Steve: Will the Mac and Linux versions also get this feature?

Torsten: Yes, it is fully compatible. This is due to the implementations of WxWidgets and my own stuff. I have already verified BLADE running under Linux. There are no differences; even the implementation code has no Windows-specific stuff.

Steve: Can you give a simple example of the workflow of a debugging session?

Torsten: First, don’t pre-load any LISP file into BricsCAD. Such code loaded outside the debugger is fully functional, but it can’t be used for debugging. The special connection between internal and external representation is only established when loading the LISP code under a debug state.

Next, in BLADE open an existing FAS or VLX project, and/or a “Named Session”, or simply any LISP file you want to start debugging with.

Now you can select Start Debugging from menu or toolbar, or hit the F8 hotkey. The special Debug Toolbar will appear. You can either activate AutoBreak, which stops at first executable code, or activate the LISP source where you want to start debugging and place some breakpoints.

Then load the dedicated LISP file, either by the normal Load into BricsCAD function, or from the Load button in the Debug Toolbar. Now that loaded code is debug-enabled and you will see the file and debug-enabled functions in the two right tabs.

When the debugger halts at the first breakpoint, all debug-step modes are enabled in the toolbar, and you have all the usual debug step modes. More than in AutoCAD’s VLIDE, actually. You can set the watches (observed and tracked variables) as “Data Break Point” by activating the checkbox. Then, whenever that value changes, the debugger also stops automatically at the related LISP statement.

Steve: What if your code calls code in other files you haven’t loaded?

Torsten: Don’t worry about that. The debugger recognizes this and will ask to load the related LISP file on-demand. In normal LISP, you would get an unknown function error but the debugger catches this upfront. In fact, this is one of the high-end features – only load the primary LISP file, any further debugging into other files resolves by loading during the debugging session. This is very handy for dealing with complex apps – there’s no need to preload any other LISP source. I’m sure you’ve experienced Murphy’s Law, where the particular function you need is the one that’s not loaded. You won’t have that problem in BLADE.

Steve: Where to from here? Is this job done or is there still room for improvement?

Torsten: As BLADE is still a very young product, there is definitely a lot more to come. So far, the main target was to provide good debugging features, and a somewhat reasonable handling of projects, but not so much focusing on plain editor capabilities.

My to-do list still has a number of major key features to be implemented. We want to add a hotkey editor, because every developer loves his own keystrokes and learning others is a nightmare! We also want cross-reference checking on a per-file and per-session basis, mainly for bigger LISP applications.

Then, over time, the editor capabilities will be extended and improved, providing more features. One example is to provide an editor tooltip that shows a function signature and short help when hovering over a LISP function name.

And of course, I’m aware that when people start using this in production, a lot of feedback will arrive from developers in the form of wishes, hints for improvements and bug reports. It’s very likely there will be many wishes to implement several details to make BLADE resemble AutoCAD’s VLIDE more closely. This could be a bit difficult sometimes, and is also not the main target. I hope that developers will be open to a slightly different workflow, given the big advantages they get in return.

In general we are very open to developer ideas, needs and requirements, as we are with BricsCAD itself. In the end, it’s the developer who needs to work with BLADE, as easily and productively as possible. Even the initial release of BLADE is based on important feedback from beta testers such as Martin Drese (CAD Wiesel).

Steve: I can certainly attest to how well you respond to feedback. I’ve seen bugs I’ve reported fixed in a very short timeframe.

Torsten, thank you for your time. This has been very illuminating.

This interview is also available in one post on the Bricsys blog.

Interviewing the creator of BLADE – CAD’s best LISP IDE – part 1

Easily the most impressive new feature of BricsCAD V18.2 is the new Visual LISP IDE, BLADE (BricsCAD LISP Advanced Development Environment). The lack of any LISP IDE has been a BricsCAD stumbling block for a while, dissuading CAD Managers from adopting BricsCAD to replace their stagnant and increasingly expensive AutoCADs.

As I will relate elsewhere, Bricsys has not just caught up with Autodesk here, but has shot so far ahead it’s unlikely to ever be caught. BricsCAD’s BLADE is so superior to AutoCAD’s VLIDE in so many ways there’s really no comparison.

Yet it remains highly compatible. I have personal experience in making large amounts of AutoCAD LISP code (literally hundreds of routines) work in BricsCAD. That experience tells me that the vast majority of code will work just fine (and much faster) in BricsCAD. A tiny proportion of LISP or DCL code may need adjustment before it will work perfectly on both platforms, and that’s one reason an IDE that works within BricsCAD was an important step that Bricsys needed to take.

I had the chance to see this IDE privately in then-unnamed pre-release form when I attended the Bricsys Conference 2017 in Paris. I was surprised and delighted at the functionality demonstrated by its creator, Torsten Moses. I recently had the chance to interview Torsten about his creation.

Steve: I understand it was difficult to create a LISP IDE for BricsCAD because of the way BricsCAD’s LISP works. Can you explain that?

Torsten: BricsCAD LISP uses the OpenLisp core system, from French developer Christian Jullien. This is the only LISP engine still under development; the others I found stopped development in the mid-90s.

OpenLisp is a very modern implementation, not comparable to the old XLisp dialect used by AutoLISP. Even object-oriented features are supported. Therefore the internal representation of LISP expressions is different from the textual representation as seen in a LISP file.

Steve: So the AutoLISP code I write isn’t the code that BricsCAD executes?

Torsten: That’s right. A number of typical AutoLISP constructions were implemented by a kind of emulation, which drives the internal versus textual representation differences even further. That makes it a major challenge to synchronize the internal OpenLisp expression execution with the related textual representation in order to provide any debugging functionality.

Besides the plain technical details, which seemed to be virtually unresolvable, there was the expected heavy effort to implement a full-blown GUI. This was not just a plain editor, but the entire IDE GUI. It would have been a disaster, a major disgrace, if we had provided a VLIDE that was just up to AutoCAD standards. That was great in its time, but it’s 20 years later now. The idea of creating a LISP IDE for BricsCAD seemed so filled with difficulties that we put it off for a long time.

Steve: How did you finally manage to overcome these difficulties?

Torsten: First, it was a pure coincidence. [laughs] By luck, I discovered a hidden detail in OpenLisp – any LISP symbol (and expressions are a kind of anonymous symbols) can hold unlimited, attached custom data, very similar to XData in DWG database objects. I even knew about that for many years, but never worked out the shortcut to ‘misuse’ this for the LISP expression execution to editor and debugger bidirectional connection. Some initial quick tests showed that this approach was very suitable.

By another coincidence, I discovered that WxWidgets (our cross-platform system, not only for GUI) already includes support for the famous Scintilla editor, an OpenSource editor engine, widely used by many editors. WxWidgets even provides two levels of wrappers – a plain, core wrapper, and a high-level wrapper class system. This fits perfectly into the WxWidgets logic.

But still, that is only plain editor support – not a GUI. Then I found a very suitable, extensible editor and GUI implementation, based on that WxWidgets Scintilla system – as Open Source under the WxWidgets license. Hence, we are allowed to use that source code in a commercial application. That editor is called wxStEdit.

I verified that this source was suitable for our LISP IDE, and put in a lot of extra work to extend it. wxStEdit development finished in around 2008, and it still was compiling and working mostly fine. Nevertheless, in the course of extending that GUI, I found and fixed a lot of defects at all related levels (Scintilla, WxWidgets Scintilla wrapper and wxStEdit).

So it was this set of coincidences that suddenly opened both wings of a big gate!

See here for part 2 of this interview.

This interview is also available in one post on the Bricsys blog.

Bricsys shows Autodesk how to do mid-term updates – again!

BricsCAD V18.2 for Windows is out. The new stuff in this mid-term update is again showing up Autodesk’s lack of progress with its once-flagship product, AutoCAD. I’m sure Autodesk would love customers to accept that there’s only so much anyone can do with a DWG-based CAD product once it reaches a certain level of maturity. Customers should get used to nothing of significance being added year after year. Diminishing returns, and all that. Pay to continue using the product, but don’t expect it to get better.

What a shame for Autodesk, then, that Bricsys exists. By consistently providing a raft of significant improvements with each full and mid-term release, Bricsys shows up that idea as nonsense. It’s perfectly possible to keep improving CAD at a very rapid rate, particularly if you’re not worried about competing with other products in your range. There’s a reason AutoCAD’s parametrics are restricted to 2D, and BricsCAD’s 3D parametrics in a DWG product proves that the reason isn’t technical. It’s strategic. Also strategic is cutting the guts out of an already much-weakened AutoCAD team, because you would really prefer your customers to be using your trendier and/or more expensive products.

I should point out that BricsCAD V18 customers who have a perpetual license, even without maintenance, will be receiving V18.2 with all its improvements free of charge. Contrast that with Autodesk, which is, despicably, withholding even bug fixes from selected customers. Autodesk’s attitude to customers who aren’t constantly paying up front is one of utter contempt. Autodesk feels entitled to your money; Bricsys wants to earn it.

So what’s Bricsys done to earn your money with BricsCAD V18.2?

Mostly, it’s lots of relatively small-sounding things that add up to significant productivity enhancements. There are several items that are playing catch-up to AutoCAD, such as long-overdue in-place text editing. There are big performance improvements in drawings with PDF underlays due to a smart multi-resolution cache mechanism. The 3D-to-2D generation mechanism has also been significantly sped up. Constraints (2D and 3D, unlike AutoCAD) are easier to create. Several 3D direct modeling operations have been made easier. That also helps with sheet metal design, which has seen other improvements.

In Bricsys BIM V18.2, a lot of smarts have been added. The mechanism for converting CAD models (including those made in BricsCAD Shape) to BIM models, BIMIFY, already did some fascinatingly clever things, but that’s been improved further particularly in the areas of structural member and room recognition. For those of us in Australia, support for our steel sections is very welcome.

For me, that’s not the big news. Oh, no. The big news for me is a thing called BLADE – the BricsCAD LISP Advanced Development Environment.

If you’re a CAD Manager or in-house developer and you’ve been waiting until BricsCAD had VLIDE, wait no longer. But this isn’t just catch-up. This is a big leapfrog over Autodesk’s sadly neglected IDE for CAD’s primary user programming language. There’s so much good stuff in BLADE that I can’t hope to do it justice here, so I will be covering it extensively in future posts. For now, here’s a statement for you:

If you program in AutoLISP or Visual LISP, you should be doing it in BLADE.

It’s that good. Really. Watch this space for details.

The download is small, the install is fast, it won’t harm your AutoCAD installation, and you can evaluate it free for 30 days. Links:

That awkward moment when I just failed to create BIM

I recently updated my resume, and I thought it might be relevant to include an episode from my early career. This post is an expansion on what I had to say about that episode.

I was managing a tiny CAD training and development company, Educad. Much of my time there was spent developing software called NIDIS (originally called NEEDS), a project that was started in 1987 or 1988 with Nixdorf Computer as the client. It was intended to take over the market among first the home building companies of Western Australia, then Australia, then the World!

What’s special about NIDIS is that it was a precursor to BIM. Using a 3D-adapted version of the 2D Educad architectural software within AutoCAD, designs of domestic homes could be efficiently created and infused with a degree of intelligence. This was then linked to the Nixdorf minicomputer-based software that contained pricing and other information about the various building components. This combined system enabled accurate quantity take-offs to be performed.

This was supposed to be a short project, but due to a massive amount of “scope creep” it took two years. I was really pushing the limits of what AutoCAD could be persuaded to do at that time and had to break new ground in several areas. Some of it was a kludge, but I made it work. Finally, the software was essentially completed, with a custom tablet menu (remember those?), full documentation and everything. Nixdorf CAD-spec PCs with big screens, tablets, AutoCAD and NIDIS were installed in the drawing office. It was successfully tested in Beta. The take-offs were very accurate. Everything looked good to go.

Then, two weeks before it was due to go into production, this project died. The building company that was sponsoring it, Mansard Homes, went into liquidation as it struggled unsuccessfully with the combined effects of very high interest rates and bad publicity about poor building quality and cost overruns. Nixdorf dropped the whole project like a hot potato and the product was never sold. I didn’t have any rights to the software and couldn’t do anything with it.

But it was software that was based around a 3D model of a building that contained some intelligent information, albeit extremely crude by today’s standards. I wrote, quite literally, Building Information Modeling software. It was completed in 1989, before the name BIM had even been used. The idea had existed since the mid 70s, but I didn’t know that at the time so I made it up as I went along.

I didn’t actually invent BIM, but I made something that resembled BIM that actually worked. And then it didn’t.

This is easily the most spectacular failure of my career. Still, I’m kind of proud of it.

Edit: for historical context, this video shows an unrelated system that was developed at about the same time as NIDIS.

How to sign your LISP files

This post follows on from Why digitally sign your LISP files? and How to obtain a digital signature to sign your LISP files.

In the first post, I explained why you might want to digitally sign your LISP files. In the second, I explained how to obtain and install a digital signature. This third and final post in the series assumes you have done all that and now want to sign your files. There are two methods available to you, using a dialog box or command-line interface.

Signing LISP using the AcSignApply.exe dialog box

Autodesk has provided a utility called Attach Digital Signatures for years. This was provided to sign drawings, zip files, etc., but the ability to sign LISP files was added in AutoCAD 2016. Don’t go using the 2015 version or you’ll have a very frustrating time! You can invoke this utility using the Windows Start Menu:

You can also make your own desktop shortcut if you like. The executable is stored at (XXXX is your AutoCAD release number):

C:\Program Files\Autodesk\AutoCAD XXXX\AcSignApply.exe

AutoCAD doesn’t need to be running when you start the application. Here’s the interface:

Half way down, there is a list of code signing certificates that you can use. You should see the one you obtained and installed earlier in this list. If you don’t see it listed it may not have been installed correctly. It’s possible to install a public key version of a certificate and see it listed in the Windows Certificate Manager, but that won’t help you sign code. You need to install the private key version in order to be able to sign things. If you do the wrong kind of export from your browser, or if you use the wrong browser to obtain and export the certificate, you may have installed the public key version. In such a case, you will need to contact the certificate provider for help. I have found that the online chat help provided by Comodo is excellent in such cases. Yes, I know this because I got it wrong the first time!

Assuming your certificate is visible, click on that line to select it. You can add files to the pane at the top left using the buttons on the right side or by simply dragging and dropping files onto the pane from Explorer. But wait! Before you do that, make sure you have a safe unsigned copy of all your files. Applying the signatures is a modification process; you are left with only the signed version of the files.

LISP files with the LSP, MNL, FAS, or VLX file extensions can be selected and dragged into the pane. As mentioned in the first post, there’s a bug in the original iterations of AutoCAD 2016 and AutoCAD 2018 that prevents signed VLX files from working, so I would advise against creating them. If you need to distribute signed DCL-based code and don’t want the LISP source visible, you will need to provide a signed FAS instead, along with a DCL file that’s either provided alongside the FAS or created on the fly by your code. Yes, this is a pain.

Note that at the time of writing, you can’t sign CUI, CUIx, DVB, JS, PGP and SCR files.

Once you have selected the certificate to use and the files to sign, select a source for the time stamp and enter a description in the Comment box (optional). Pick the Sign Files button and you’re done.

Signing LISP using the AcSignTool.exe command-line utility

This utility isn’t provided with AutoCAD, but you can download it here. It doesn’t require AutoCAD, which means you can sign LISP files even if you don’t have a copy of AutoCAD 2016 or later.

Once you have downloaded and unzipped the file, place the files somewhere handy. If you make a shortcut to cmd.exe that starts in that location, you can run this command to see all the options:

acsigntool.exe /?

Usage is usually as follows:

AcSignTool -sign /file:[inputfile] /cert:[certificate] /time:[timestamp] /comment:[description]

Here’s an example:

AcSignTool -sign /file:"X:\ToSign\MyCode.lsp" /cert:abcdef1234567890 /time:1 /comment:Hello

The resultant file should be the same as with the dialog box interface. If it’s a raw LISP file, a large comment like this will be placed at the bottom of the file:

;;;-----BEGIN-SIGNATURE-----
;;; /gcAADCCB/oGCSqGSIb3DQEHAqCCB+swggfnAgEBMQ8wDQYJKoZIhvcNAQELBQAw
;;; IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD
;;; CwYJKoZIhvcNAQcBoIIFQzCCBT8wggQnoAMCAQICEQCyNMZT2aa05avqeC3j+F3p
;;; YQBuAGQAYQByAGQAcwAgAGEAbgBkACAAVABlAGMAaABuAG8AbABvAGcAeQAgACgA
;;; MA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
;;; QSBMaW1pdGVkMSMwIQYDVQQDExpDT01PRE8gUlNBIENvZGUgU2lnbmluZyBDQTAe
;;; bnB31gkc9o/M8YjPdGVjQG0VS96RVf/WtkmGugV2n1Fv4wWXBLA7n410yglqSZh9
;;; NOK2Ya1KFx4trccIHV1oAFN+BCKzSf6J/HdVkmCcy4TEPcrxSzZsi//slm2o9EHl
;;; mwdm6Quhw1wMT8+iRmJNO4ofwuKfBwyE28ZIK4q+zorJPNwiK2o43CmNJViU5SQD
;;; M9ImVtHTTtdAR1Iln+wEtg/4xgwj5KWuxoUJ22OJ/K0A8IcnxqGBujCBtwYDVR0O
;;; Fw0xNzEwMDQwMDAwMDBaFw0yMTEwMDQyMzU5NTlaMIGAMQswCQYDVQQGEwJBVTEN
;;; MAsGA1UEEQwENjE1NTELMAkGA1UECAwCV0ExEjAQBgNVBAcMCVdpbGxldHRvbjEV
;;; A1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JT
;;; QUNvZGVTaWduaW5nQ0EuY3JsMHQGCCsGAQUFBwEBBGgwZjA+BggrBgEFBQcwAoYy
;;; aHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ29kZVNpZ25pbmdDQS5j
;;; MYGvBIGsOAAyADsAMgAvADEAMAAvADIAMAAxADgALwA4AC8AMgA2AC8AMQA3AC8A
;;; TgBhAHQAaQBvAG4AYQBsACAASQBuAHMAdABpAHQAdQB0AGUAIABvAGYAIABTAHQA
;;; dABpAG0AZQAtAGEALgBuAGkAcwB0AC4AZwBvAHYAKQAAAA==
;;; -----END-SIGNATURE-----

Because it’s a comment, it will be ignored by AutoCAD releases prior to 2016, and by other AutoLISP-compatible CAD applications such as BricsCAD and ZWCAD.

References:
Signing your application modules for AutoCAD 2016 – Part 1 – Kean Walmsley
Signing your application modules for AutoCAD 2016 – Part 2 – including various other references
To Digitally Sign an AutoLISP File – Autodesk Knowledgebase article

How to obtain a digital signature to sign your LISP files

In an earlier post, I explained why you might want to digitally sign your LISP files. If you decide to go ahead with that, then this post explains how you can obtain and install the digital signature you will need to sign your files. This is the most difficult part of the process and it involves spending money.

Getting a digital signature

Although you can make your own digital signature (there’s an Autodesk Knowledgebase article describing the process), there’s little point in doing this. You can sign your files, sure, but that signature won’t be seen as trusted by software that checks for it. Anybody can create a signature like that, including one that impersonates you, and it doesn’t prove anything. The only purpose for such a home-made signature would be to test the methods you’ll be using to apply a proper trusted signature later.

Edit: if you do want to make your own signature, BlackBox informs me that the MakeCert tool in the Windows SDK mentioned in the Knowledgebase article is deprecated. He suggests using this PowerShell Cmdlet instead.

You’re going to need a signature that is trusted. That means you’re going to have to pay somebody trustworthy to trust you. There are a set of certifying authorities, trusted by Microsoft, Autodesk, etc. who can issue code signing certificates to companies and people. You need to prove who you are to one of those authorities and pay them to certify that you are who you say you are. So before you start, make sure you or your business are visible in terms of directory listings, publicly visible phone numbers, etc. If you are representing a company asking for a certificate, you can expect to be asked to produce evidence that you really represent that company. You can expect to confirm that your email and phone number are really under your control.

You only need to do this once a year, or even once every several years if you pay in advance. You might find that the evidence you need to provide changes at renewal time; for example a Yellow Pages listing that was OK in 2015 was no longer accepted when I renewed in 2017, so I had to register my business with another listing.

In my search for a certifying authority, I found that K Software, a reseller for Comodo, was the cheapest source for a code signing certificate, see here. An OV certificate will be fine for signing LISP.

K Software takes your money (USD $67 to $84 a year depending on the length of time you need), gets Comodo to provide the certificate, and provides a handy tool (KSign) that allows you to simply apply the certificate to various files without some of the messing about that’s otherwise required. It’s not useful for LISP files, though. Comodo also provides the support, and I’m happy to report that in my experience their customer service is excellent.

Note: it’s important that you pay close attention to the instructions when applying for your certificate. For example, the browser you use to apply for the certificate is vital. Choose one that’s suggested (e.g. Firefox) and which you expect to use later to obtain the certificate.

Installing a digital signature

Once your evidence is accepted and your payment has gone through, you will be sent an email with a special code, allowing you to obtain the certificate. It’s important that you’re using the same browser on the same computer that you used when applying for the certificate.

Once you click the link and obtain the certificate, you’ll want to export it. In Firefox 58.0, use Options > Privacy & Security and scroll to the bottom to see View Certificates. Select the certificate and pick Export. This will create a .P12 file that you can back up and install on this or another computer. To install the certificate, double-click the .P12 file and follow the prompts to assign it to the current user in the default location (Personal).

That’s it. You should now have a certificate installed that you will be able to use to sign LISP and other files. To check this, start the Windows Certificate Manager (C:\Windows\System32\certmgr.msc). Have a look in Current User > Personal > Certificates and you should find your newly installed certificate.

The next post in this series will explain how to apply this digital signature to your LISP files. That’s the easy bit.