In this third post in what was supposed to be a two-part series, I have more to say about the BricsCAD documentation system. See here for part 1 and here for part 2.
Developer Help – Addendum
In this comment from Bricsys API person Torsten Moses, he informed me about the availability of the Lisp Developer Support Package (LDSP) in the Bricsys Application Catalog. As always, when presented with new evidence I am prepared to re-examine my position on anything. Therefore, I will now further discuss the BricsCAD developer documentation.
The first thing to mention is that the existence of the LDSP package is not obvious. To somebody who uses BricsCAD as-provided and as goes burrowing down through the Help system looking for information, that system is still broken. The …
In this pair of posts, I describe the BricsCAD documentation system. Click here for part 1, where I describe the general Help system and the descriptions in the Settings command.
In this part, I discuss developer documentation and draw my conclusions.
If we count the Settings descriptions as a system, there’s a third documentation system for BricsCAD. The Developer Reference isn’t offline and included in an install like the main Help. Instead, it’s online, just like Autodesk’s default. Unlike Autodesk’s system, it works pretty well.
Being online means the performance suffers, of course, but it’s generally not too bad. It appears quicker than Autodesk’s. A link within the main Help system takes you to the Bricsys Developer Reference which is just accessed using your default browser. Of course, that means your mouse buttons work correctly and you have all other the advantages of whatever …
Because of the great similarity between BricsCAD and AutoCAD in terms of commands, variables and most aspects of usage, you would expect the BricsCAD documentation to be about the same too. But it isn’t. Much of the content covers the same areas and due to BricsCAD’s command-line compatibility, there must be a lot in common. But the Help system is very different from Autodesk’s. How so?
In this pair of posts, I describe the BricsCAD documentation system. I assume you’re familiar with the AutoCAD one. In this first part, I describe the general Help system and the descriptions in the Settings command. In part 2, I will discuss developer documentation and draw my conclusions.
The general Help system in BricsCAD looks a lot like the excellent CHM-based system that AutoCAD had in 2010 and earlier (thanks, Dieter). BricsCAD’s Help is offline by default, included with the …
In a previous post, I showed that AutoCAD is bloatware by comparing the size of its downloads to that of BricsCAD. Obviously, an application that’s ten times the size it should be is going to cost you a lot of unnecessary bandwidth, download time and drive space. But maybe you don’t care about that. What practical difference does it make?
Well, for one thing, the blimping-out of Autodesk’s former flagship product has a big effect on installation time. Vast and ever-increasing amounts of time are wasted by users of Autodesk products, just waiting for the things to finish installing. But isn’t this just the inevitable price to pay for the functionality provided?
No. Again, BricsCAD proves it.
The installation comparison is shown below. These installations were performed on a mid-range Windows 10 i7 PC with 8 GB RAM. The downloaded files were executed from a local hard drive …
You may have seen me mention in passing that AutoCAD is bloatware. That’s not just the general grumpy-old-user moan you see from long-term users like me, who can remember when AutoCAD used to fit on one floppy disk.
Yes, programs get bigger over time as new functionality is added and old functionality needs to be retained. Hardware gets bigger, better, faster over time to compensate for that. I get that. Understood.
The AutoCAD bloatware problem is much more than that. AutoCAD is literally ten times the size it needs to be, to provide the functionality it does.
How do I know? BricsCAD proves it. Here’s what I mean.
BricsCAD V17.2 64-bit Windows Download
Downloaded File Size (KB) BricsCAD-V17.2.03-1-en_US(x64).msi 248,812 Total (1 file) 248,812 (100%)
Equivalent AutoCAD 2018 Downloads
Downloaded File Size (KB) AutoCAD_2018_English_Win_64bit_dlm_001_002.sfx.exe 2,065,829 AutoCAD_2018_English_Win_64bit_dlm_002_002.sfx.exe 328,277 AutoCAD_2018.0.1_64bit_r2.exe 120,663 AutoCAD_2018_Product_Help_English_Win_32_64bit_dlm.sfx.exe 180,013 Total (4 files) 2,694,782 (1083%)
Which dog is which? They’re both …
BricsCAD V17.2 is out. Although there’s nowhere near as much new and useful in this mid-term update as in the full upgrade from V16 to V17, there’s more here than in Autodesk’s last mid-term update, AutoCAD 17.1. There’s even arguably more than in the uninspired AutoCAD 2018 upgrade, including those 17.1 features.
But that’s not the main reason I say Bricsys is schooling Autodesk in how to do mid-term updates. While Autodesk is restricting such updates (including the bug fixes and security updates included in those updates) to subscription and maintenance customers, Bricsys is doing no such thing.
BricsCAD V17 customers who have a perpetual license, even without maintenance (called All-In by Bricsys), will be receiving V17.2 free of charge. Bricsys still considers such users as customers who have paid good money and still need to be looked after, rather than a non-paying irritant, …
If you’re a power user or CAD Manager transitioning from AutoCAD to BricsCAD, one of the things you’ll like is that almost all of your LISP routines will just work. That’s not an statement that can be made about various Autodesk products that bear the AutoCAD name, such as AutoCAD 360, AutoCAD LT and AutoCAD for Mac.
It’s not just simple old AutoLISP code that runs in BricsCAD, but complex dialog routines that use DCL, and Visual LISP stuff that uses ActiveX. Yes, even on the Mac and Linux platforms. Some DOSLib functions are built in and the rest can be loaded, as with AutoCAD. Even OpenDCL is supported. It’s a quite astonishingly high level of compatibility.
But it’s not 100%. There are minor incompatibilities, system variable and command-line differences that cause problems in a handful of cases. It’s often possible to work around these and still retain …
A big problem I have in communicating the improvements to BricsCAD in V17 is that there are such a huge number of them. This isn’t an AutoCAD 201x-style touch-up masquerading as serious progress, this is a real upgrade. You know, an AutoCAD V12-style upgrade that veteran AutoCAD users will remember from the good old days before Autodesk got bored and distracted. Dozens upon dozens of new features, improvements to existing features, performance improvements and bug fixes. Lots of stuff that’s genuinely useful.
I could write three posts a week on the changes and not be finished by this time next year. So I’m going to be lazy. I’ll pick out a few features for future posts but for the big picture I’ll point you to the official list. This isn’t a marketing document, it’s a technical list of terse descriptions of changes (to the Windows version only – …
I’ve been evaluating BricsCAD for a few years now, and have been looking at it pretty seriously as a DWG-based LISP-compatible AutoCAD alternative for a year or so. A couple of weeks ago, I flew to Munich for the Bricsys International Conference (at Bricsys’ expense – see the Legal page for disclosure) where I learned quite a few things I had failed to notice during my own evaluation of V17. As you may have noticed, I can be pretty hard-bitten and cynical about what CAD companies have to say about their products, but I came back impressed.
The conference and the product itself are not free of flaws, but I have to say the progress Bricsys has shown in developing the BricsCAD product is really quite astonishing. The rate at which serious, worthwhile-to-customers improvements have been made to BricsCAD over the last few releases is huge. Some of …