Topic: Sharing partial MNS in 2007

[dan19936]

I'm setting up basic customization for an office on 2007 (and I'm not). I've got access to an installation on a laptop for testing, but won't be using it regularly at all. The customization is a MNS file with a drop down & one toolbar. I've got the MNS to load fine in 2007 on the laptop, however I'm concerned about having the MNS shared across the network for all stations because of the CUI file that is created. Is there a problem having those files shared (with the assumption that users will not be modifying the toolbar or menu).

Thanks,

Dan

[Joe Burke]

Dan,

I don't know if this will help and I'm no CUI expert.

When you load filename.mns the first time, filename.mnr and filename.cui are created. After that, there is no link between filename.mns and the other two files. An edit to filename.mns will not update the interface.

Assuming you want to continue to edit/modify using the filename.mns file, rather than edit the .cui file itself in the CUI editor, do this. Modify the .mns as needed. Unload and reload the .mns file. That will update the related .mnr and .cui files.

HTH

[dan19936]

Joe,

Thanks - I'm familiar with MNS vs. MNRs and have successfully figured out how to modify & reload as required. I'm concerned that autocad won't like multiple computers pulling the same MNR (or will it be the CUI?) from the network. For instance if someone makes a change to their local CUI, will it affect the network shared MNR/CUI? I'm trying to avoid learning about full CUI implementation and enterprise CUIs since I have limited time and limited access to their network. Also since I have limited access I'm trying to find out if I need to make the plunge before I deploy the customization. (Which at this point is one drop-down menu w/two items, a toolbar, an s::startup, and a lisp/DCL for dimension standards setup.)

Dan

[Joe Burke]

Dan,

The .mnr file is updated when the .cui file is modified using the CUI editor.

I'm not sure what you mean by, "if someone makes a change to their local CUI". I was under the impression you wanted to put your custom CUI file on a server, so all machines would access it from there. Maybe you mean if someone makes a change to their local ACAD.CUI file? If so, I don't think that would affect your custom CUI on the server.

Obviously what would be a concern is someone modifying your custom CUI on the server with the CUI editor. That would affect all users, not good.

I'm sure others here can offer better advice than myself. My experience with the questions you are asking is limited.

[dan19936]

Maybe you mean if someone makes a change to their local ACAD.CUI file?

Yup.

If so, I don't think that would affect your custom CUI on the server.

OK good, thanks for the response. I'll postpone diving into CUIs unless I have problems.

Dan

[sinc]

Maybe you mean if someone makes a change to their local ACAD.CUI file?

Yup.

As a general rule, you should try to avoid editing the ACAD.CUI file.

Part of the whole goal of the CUI was to keep everyone from having to do so much updating of customization between versions.  That's why they implemented the Partial CUI strategy.  Autodesk itself will update things like ACAD.CUI between versions, which means that you will lose your customizations if you change that file.

In general, the ACAD.CUI file is intended to be a Partial CUI that you never edit.  Then you edit a custom CUI that links in the ACAD.CUI as a partial.

Autodesk also intended company-wide information to be placed into an Enterprise CUI, and then each user could have their own custom Main CUI that they could edit as they wished.  However, Autodesk's implementation has been TERRIBLE, and this doesn't really work.  You can sort-of get it to sort-of work in some ways, but it is a huge headache.  I've given up trying to use Enterprise CUIs until 2008, because the software has so many problems that I've found them to be too big a time-waster, and regardless of what you try, you probably won't be able to get them working right...

[CADaver]

Part of the whole goal of the CUI was to keep everyone from having to do so much updating of customization between versions.  That's why they implemented the Partial CUI strategy. 

Menuloading additional custom menus worked just fine for that, so far, much better than the CUI debacle.  I'm not sure what precipitated the switch, but that wasn't it.

Autodesk also intended company-wide information to be placed into an Enterprise CUI, and then each user could have their own custom Main CUI that they could edit as they wished. 

Again menuloading worked quite well for that, so far, much better than the CUI debacle.

[Joe Burke]

Maybe you mean if someone makes a change to their local ACAD.CUI file?

Yup.

As a general rule, you should try to avoid editing the ACAD.CUI file.

Part of the whole goal of the CUI was to keep everyone from having to do so much updating of customization between versions.  That's why they implemented the Partial CUI strategy.  Autodesk itself will update things like ACAD.CUI between versions, which means that you will lose your customizations if you change that file.

In general, the ACAD.CUI file is intended to be a Partial CUI that you never edit.  Then you edit a custom CUI that links in the ACAD.CUI as a partial.

Autodesk also intended company-wide information to be placed into an Enterprise CUI, and then each user could have their own custom Main CUI that they could edit as they wished.  However, Autodesk's implementation has been TERRIBLE, and this doesn't really work.  You can sort-of get it to sort-of work in some ways, but it is a huge headache.  I've given up trying to use Enterprise CUIs until 2008, because the software has so many problems that I've found them to be too big a time-waster, and regardless of what you try, you probably won't be able to get them working right...

Personally I figured I would not fully understand the why of CUI until I upgrade from 2006 to 2007. Which I nave not done yet.

I *thought* the reason for it was pretty much the opposite of what you said above. That a newer version would look at the previous version CUI and intelligently incorporate what applies. Otherwise, what's the point?

Of course, I may be dead wrong...

[sinc]

I *thought* the reason for it was pretty much the opposite of what you said above. That a newer version would look at the previous version CUI and intelligently incorporate what applies. Otherwise, what's the point?

Of course, I may be dead wrong...

The main idea behind the CUI is that it incorporates ALL customizations into a single place, with a coherent GUI to modify the whole shebang.  Not just menus, but EVERYTHING.  In theory, it's a great idea.  The old way had customizations sprinkled through lots of files that had to be manually-edited with text editor, and it was something of a pain to edit files and keep everything synchronized, since pieces were sprinkled through so many files in so many different directories.

A couple years back, someone at AUGI wrote a huge 3-part article explaining how to "easily" move all customizations from one installation from another.  It involved scripts and lots of headache, but it was the easiest way, prior to the CUI.

Unfortunately, Autodesk's implementation of the CUI has been atrocious.  So people who had a handle on how to use MNL files before are now angry, because the CUI doesn't work very well.  In theory, if they ever get the code written right, it will be very easy to customize ALL aspects of Autocad from a single GUI, and everyone will be very happy.  But in the meantime, we are all stuck suffering immensely...

[Joe Burke]

I would suggest, speak for yourself, rather than assume everyone agrees with you.

I'm not "suffering immensely" over this stuff. Maybe "drama queen" rings a bell? 

[sinc]

I would suggest, speak for yourself, rather than assume everyone agrees with you.

I'm not "suffering immensely" over this stuff. Maybe "drama queen" rings a bell? 

No, I greatly doubt "drama queen" is correct.

But you're probably right.  It causes the most problems for people who a) try to use partial CUIs, b) try to use Enterprise CUIs, and c) use Vertical Apps (such as Land Desktop, etc.).  If you don't fall into any of those categories, you don't see the worst of the problems, and you avoid most of the headache.  Unfortunately, ALL of them apply to us.

And if you regularly need to use more than one vertical app, it gets much worse...

[CADaver]

The main idea behind the CUI is that it incorporates ALL customizations into a single place, with a coherent GUI to modify the whole shebang.  Not just menus, but EVERYTHING.  In theory, it's a great idea. 

yep... in theory

The old way had customizations sprinkled through lots of files that had to be manually-edited with text editor, and it was something of a pain to edit files and keep everything synchronized, since pieces were sprinkled through so many files in so many different directories.

So far it was MUCH easier than attempting multiple client customized CUI's running.

A couple years back, someone at AUGI wrote a huge 3-part article explaining how to "easily" move all customizations from one installation from another.  It involved scripts and lots of headache, but it was the easiest way, prior to the CUI.

Network installs solved that

Unfortunately, Autodesk's implementation of the CUI has been atrocious.  So people who had a handle on how to use MNL files before are now angry, because the CUI doesn't work very well. 

"very well"?? try "at all"

In theory, if they ever get the code written right, it will be very easy to customize ALL aspects of Autocad from a single GUI, and everyone will be very happy. 

Why should I be happy about being forced to use a bloated GUI to change a button prompt?  

But in the meantime, we are all stuck suffering immensely...

or banging away at it until it works or R2010 comes out.

[sinc]

Why should I be happy about being forced to use a bloated GUI to change a button prompt? 

I agree that Autodesk's implementation has been terrible.  But if the CUI weren't so buggy, and so ssssslllloooowwww, then you may get a different impression.  A well-designed GUI is ALWAYS easier to use than digging through a bunch of configuration files, all located in different directories.

If you disagree, then I would hazard that is only because you are very familiar with the "old" way.  Try to imagine it from the perspective of someone who doesn't have years of experience customizing Autocad.  If the GUI worked well, then someone with very little experience in Autocad could do customizations that it used to take years of experience in order to achieve.  I would say that is a very good change.  Any change that makes a task much easier to learn and much easier to perform is worth it.  Unfortunately, the current implementation of the CUI is so bad that, at this point, it is arguable that it is any improvement, but I still hold out hope that Autodesk will eventually work it out...  Hopefully before 2010, but judging from what they've done so far, you might even be optimistic in your time estimate...   

[CADaver]

A well-designed GUI is ALWAYS easier to use than digging through a bunch of configuration files, all located in different directories.

I wouldn't know, so far I have never seen a "well designed GUI".  So far all I've seen is a bloated buggy interface that eats a usable seat just for customization.

If you disagree, then I would hazard that is only because you are very familiar with the "old" way.  Try to imagine it from the perspective of someone who doesn't have years of experience customizing Autocad.  If the GUI worked well, then someone with very little experience in Autocad could do customizations that it used to take years of experience in order to achieve.  I would say that is a very good change. 

I'd say you're living in a dreamworld.  Look at the real world and imagine someone with little experience in AutoCAD attempting personal customizations on a networked system using the current GUI.  HINT: Experience is a GOOD thing.

Any change that makes a task much easier to learn and much easier to perform is worth it. 

When that happens, let me know.

Unfortunately, the current implementation of the CUI is so bad that, at this point, it is arguable that it is any improvement, but I still hold out hope that Autodesk will eventually work it out...  Hopefully before 2010, but judging from what they've done so far, you might even be optimistic in your time estimate...   

Unfortunately for Autodesk it may be too little too late.  Those of us forced to live in a production world have already began to seek out (and find) alternatives for AutoCAD.  If I have to live with a bloated heavy-handed interface, why not get some bang for the buck.  Our structural guys are already moving away in favor of big guns like Tekla, that provide fabrication details dang near free.

[sinc]

If you disagree, then I would hazard that is only because you are very familiar with the "old" way.  Try to imagine it from the perspective of someone who doesn't have years of experience customizing Autocad.  If the GUI worked well, then someone with very little experience in Autocad could do customizations that it used to take years of experience in order to achieve.  I would say that is a very good change.

I'd say you're living in a dreamworld.  Look at the real world and imagine someone with little experience in AutoCAD attempting personal customizations on a networked system using the current GUI.  HINT: Experience is a GOOD thing.

I think I very clearly said that the current GUI is a terrible mess.  It's difficult for ANYONE to use this thing, except in a basic fashion.

But I really don't think I'm living in a dream world.  Since I have a lot of exprience with Unix systems (Sun systems, NeXT, MacOSX), I actually have a lot of exprience with well-designed software.  That's one of the reasons I find Windows so frustrating.  If it weren't for Autocad, I probably wouldn't be using Windows at all.

I also have a lot of exprience as a software designer, designing easy-to-use GUIs.  In my opinion, every time a user has to refer to the help, it illustrates another aspect of the program that might potentially benefit from redesign.  There is really no good reason that someone with a lot of experience in construction should need to spend years learning to use the program that's supposed to make life easier.  Sure, they need to spend years learning the biz, but they shouldn't need to spend years learning the software.

Well-designed software is very easy to use, assuming the user fully understands the problem space.  The user should merely have to think "I want to accomplish this task...", and it should be very easy to just perform the task.  It's impossible to completely eliminate the need for Help, but it SHOULD be possible to eliminate lengthy training.  There is actually an awful lot of software that is intuitive and easy-to-use, just not a whole lot of it on the Windows platform.  People who have spent their whole life using Windows don't know what they're missing.

OK, so maybe you're right, and I am living in a dream world.  If Windows has been around for over 20 years and it's STILL like this, then there's no reason to hold out hope that it will change.  Maybe Apple will eventually come to their senses, and make their OS so that it can run on ANY machine that currently runs Windows, rather than just on the limited hardware they currently support.  Then it's possible that more and more people will start to see the REAL differences between the two, rather than simply saying that OSX is basically Windows with eye candy (a VERY wrong analysis).

[CADaver]

But I really don't think I'm living in a dream world.  Since I have a lot of exprience with Unix systems (Sun systems, NeXT, MacOSX), I actually have a lot of exprience with well-designed software. 

I to have had a lot of experience with other systems including those mentioned.  Please point out this well-designed software you keep talking about.  NONE of the GUI CAD systems with which I am familiar are any better that the one currently plaguing AutoCAD.

I also have a lot of exprience as a software designer, designing easy-to-use GUIs. 

I'm not looking for easy to use, I'm looking for easy to customize

There is really no good reason that someone with a lot of experience in construction should need to spend years learning to use the program that's supposed to make life easier.  Sure, they need to spend years learning the biz, but they shouldn't need to spend years learning the software.

Again, I'm not talking about using the software but customizing it for specific tasks.  I completed editing my first menu for AutoCAD about twenty minutes after installing the software the first time, but then I was already familiar with EDLIN at the time.  It was a lot easier after we installed Word for DOS.

There is actually an awful lot of software that is intuitive and easy-to-use, just not a whole lot of it on the Windows platform.  People who have spent their whole life using Windows don't know what they're missing.

CAD software?? Okay, I'll bite, which would those be?

[sinc]

CAD software?? Okay, I'll bite, which would those be?

Again, if there were any decent CAD programs for Mac OSX, I would undoubtedly be using that, instead of Autodesk's stuff.  Unfortunately, if there is one, I haven't found it.

But just to give an idea of "good design" vs. "bad design", check out Carlson Survey, and compare it to the survey functionality in Land Desktop.  True, Carlson is built-on Autodesk software, so it's nowhere near as good as it could be if the underlying software were designed as well, but it is FAR more intuitive to use.  Most surveyors can start using Carlson MUCH MUCH faster and easier than they can Land Desktop.  The general comment is that "Carlson seems like it was designed by a surveyor.  Land Desktop seems like it was designed by a software engineer."

And the process continues.  C3D is easier to use than Land Desktop, but a lot of Civil-3D could be much, much simpler than it is.  My own fear is that Autodesk views making software really easy to use would cut into the profits they're getting from selling consulting services and training.  I truely hope I'm wrong about that, but all evidence points toward it being the case.

[CADaver]

CAD software?? Okay, I'll bite, which would those be?

Again, if there were any decent CAD programs for Mac OSX, I would undoubtedly be using that, instead of Autodesk's stuff.  Unfortunately, if there is one, I haven't found it.

So "dreamworld" is a LOT closer to accurate, we're back to "I have never seen a "well designed GUI". 

But just to give an idea of "good design" vs. "bad design", check out Carlson Survey,...

SurvCADD?? You're kidding right? Have you ever tried to customize that piece of ... of work??

And the process continues.  C3D is easier to use than Land Desktop, ...

You're still looking at "easy to use"..., I'm looking for easy to customize. A GUI for customization that eats a production seat is less than helpful.

[Joe Burke]

sinc,

Just curious, have you looked at PowerCADD by Engineered Software? It's Mac only CAD program with a loyal following dating back to around 1988. It was called PowerDraw back then, when I used it.

There's an add-on for it called WildTools by a guy named Alfred Scott. He's an old friend. Though it has been about 16 years since I used PowerDraw/PowerCADD, I still converse with Alfred about programming issues. Primarily about interface things.

Regarding Mac vs. Windows, I used Macs for CAD from 1985 to 2000. Almost 10 yeas with Microstation Mac.

To me the OS is meaningless. I'm only interested in what the CAD software can or can't do.

BTW, I liked the feel of the old Mac OS pre OSX. Which is pretty much what Windows is today, with all the good stuff added.

When I look an an OSX machine now, I'm just confused. And I think for no good reason... other than Apple thinks it has to look different.

Also interesting, Apple recently changed it's name from Apple Computer to simply Apple.

[cdavis]

poor Dan, never really did get his question answered in between the arguing.
I manage a cad system for approx 100 seats over 3 different departments that all wanted something different.  What IS the same for everyone though is exactly what you're trying to do.  (and it isn't problematic, verticals or not.)
After the cui & mnr files are created you can trash the mns.  It's worthless unless you plan on maintaining the same thing in two different places and want to assume autodesk isn't going to do anything strange later on down the road...
Your concerns seems to be everyone sharing the menu, and nobody being able to edit it.  Make it the enterprise menu PLUS store it in a location on the network that only authorized users have Write access to.

and just of note, someone said,
"It's difficult for ANYONE to use this thing, except in a basic fashion."
Uh, no. No it isn't.  It is difficult for YOU.
“Argue for your limitations, and sure enough they're yours.” -Richard Bach

[CADaver]

I manage a cad system for approx 100 seats over 3 different departments that all wanted something different. 

Try over three hundred users, five departments, twenty-seven clients, each with a completely different set of needs and standards (that worked seamlessly in previous revision without eating a seat of AutoCAD to edit)

What IS the same for everyone though is exactly what you're trying to do.  (and it isn't problematic, verticals or not.)
After the cui & mnr files are created ...

How do you edit the CUI??  (oh, BTW all seats are currently in use)

and just of note, someone said,
"It's difficult for ANYONE to use this thing, except in a basic fashion."
Uh, no. No it isn't.  It is difficult for YOU.

Fair enough, but if you'l just pass over ANY AutoCAD forum since the inception of the poorly thought-out roll-out of CUI, I think you'll find that "I'm" not alone in my opinion of the piece 'o crap.  And to a point you're right, it's not really difficult, just massively MORE a PITB than it was prior.

[sinc]

"It's difficult for ANYONE to use this thing, except in a basic fashion."
Uh, no. No it isn't.  It is difficult for YOU.

If you really think that, then please write an article explaining how to use the CUI to setup customizations for a vertical app like Land Desktop.  Important parts are: a) use Enterprise CUIs for the company-standard part, so that average users cannot edit the company-wide customizations b) still allow the user to easily create and manage a Custom.cui as their personal Main CUI.  Note that the user should not run into ANY unresolved references, toolbar buttons that look like clouds, bogus menus appearing in the Land Desktop "Points" menu, etc.  And it must be easy to move those customizations to the next version of Autocad when it comes out.

If you can actually write an article explaining the above, then I will bow down and worship you.  Otherwise, I don't believe you.

[CADaver]

If you can actually write an article explaining the above, then I will bow down and worship you.  Otherwise, I don't believe you.

gee sinc, it "was" the guys first post, you coulda cut him some slack ...

...

... nah you're right, I guess not, me neither.

[ronjonp]

To share across a network without having to worry about users making changes to the CUI file.....make the file read only.

Am I missing something here?

[CADaver]

To share across a network without having to worry about users making changes to the CUI file.....make the file read only.

Am I missing something here?

That's not the problem with CUI.  The current implementation of CUI is heavy-handed and eats a production seat during customization.

[ronjonp]

Cadaver,

What do you mean by "eats a production seat"?

Ron

[CADaver]

Cadaver,

What do you mean by "eats a production seat"?

Ron

I have to be running AutoCAD.

[dan19936]

I have to be running AutoCAD.

I'm impressed you can customize your setup without testing it on AutoCAD. I'm guaranteed to have a typo anytime I mess with anything.

[CADaver]

I have to be running AutoCAD.

I'm impressed you can customize your setup without testing it on AutoCAD. I'm guaranteed to have a typo anytime I mess with anything.

In older versions I can do a ton of menu mods using Notepad editing the MNS during the day. Then after hours, compile the menu do the checks,  make a few repairs and the new changes are in place in a few minutes.  Now I have to eat a production seat to make the changes to a dummy CUI for testing so as not to screw up concurrent work, then after hours roll out the changes and check the production CUI for function.

[sinc]

If you can actually write an article explaining the above, then I will bow down and worship you.  Otherwise, I don't believe you.

gee sinc, it "was" the guys first post, you coulda cut him some slack ...

...

... nah you're right, I guess not, me neither.

Yeah, I coulda cut some slack.  Guess I've spent so much time trying to debug this CUI that having someone say "It's simple" without providing any real help got my gumption up.  Still, if he could manage to put together an article explaining how to get everything to work right, he would elate a huge number of people.

When it comes to Land Desktop, Civil Design Companion, and Survey (the primary package we've been using up until recently), the closest I've come to getting everything working goes something like this:

Make a copy of CUSTOM.CUI, and call it "Company.CUI".  Place all custom commands and scripts in this CUI.  (In order to do this, set Company.CUI as your Main CUI in OPTIONS - then you can edit the CUI in the CUI editor.)  Make sure you also change the name of the customization group in the CUI editor - i.e., at the very top of the tree in the upper-left portion of the CUI editor, make sure you change "CUSTOM" to say "COMPANY".  Then add your custom commands to toolbars as desired.  You can also link in basic CUIs like ACMAP.CUI and EXPRESS.CUI if you want to add some of those commands to some custom toolbars.  Just keep in mind that this CUI should be considered a "Base" CUI, so it should have no Land Desktop, Civil Design, or Survey commands in it.

Create another copy of custom.CUI, called "CompanyLand.CUI" (remember to also change the name of the customization group in the CUI editor).  Make a copy of "Land.DLL", and call it "CompanyLand.DLL".  Set CompanyLand.CUI as the Main CUI in OPTIONS.  Make sure you change the name of the CUI group from "CUSTOM" to "COMPANYLAND".  Link in all of the following as Partial CUIs, in this order: LAND.CUI, ACMAP.CUI, ACETMAIN.CUI, CIVILDESIGN.CUI, SURVEY.CUI, Company.CUI.  It's a real pain linking in all these CUI files, because of the way the CUI editor works, but that's par for the course.  Now, in CompanyLand.CUI,  create all custom commands and toolbars that have anything to do with Land Desktop, Civil Design Companion, or Survey.

At this point, you should have a main CUI that works for everything except for creating custom toolbars that contain Map commands.  For some reason, all Map tool buttons turn into clouds when you add them to a new toolbar.  I think you can get around this if you can combine all the icons in "acmap.DLL" and "land.DLL" into a single file called "CompanyLand.DLL", but I'm not entirely sure how to do that.  I think I remember seeing something about it once, but I believe it involved a little utility someone wrote.  (And you can actually get around the icon problem by saving a copy of the icon to a BMP file, and then pointing your new toolbar button icon to the BMP file.  This is rather annoying, but it works.)  At this point, everything else seems to work (I think).

Here's where the real problems start.  Create a new CUI file, called "User.CUI", and set it as the Main CUI.  (Again, make sure to also change the name of the customization group in the CUI editor.)  Make another copy of "land.DLL", and call it "User.DLL".  Now set User.CUI as the Main CUI, and CompanyLand.DLL as the Enterprise CUI.  The user can now create new toolbars, but with the same issue as before (all Map toolbar icons will appear as clouds).  In addition, shortcut menus defined in User.CUI are ignored, so the user cannot customize those.  Also, if you go into the CUI and attempt to edit one of your workspaces, you will see that all menus show up as "Unresolved reference" in the upper-right quadrant of the CUI editor.  Attempting to use the Transfer tab to transfer in workspaces results in erratic results.

That's about the best I can manage.  At least it should be relatively easy to upgrade, though, since the Autodesk-provided CUI files are not edited, and can be simply replaced with the new ones when the new version comes out (excepting, of course, any changes Autodesk may have made, like in 2007 when they moved all the Layer Tools from ACETMAIN.CUI to ACMAP.CUI, forcing the user to re-create any custom toolbars that included Layer Tools).

Randomly, the "Recent Commands" menu may appear inside the Points menu at the top of the screen.  I don't know why.  I think it has something to do with shortcut menus getting mixed up with normal menus, but since the Land Desktop "Point" shortcut menu is not included in the CUI, it's difficult to tell what's going on.

[sinc]

sinc,

Just curious, have you looked at PowerCADD by Engineered Software? It's Mac only CAD program with a loyal following dating back to around 1988. It was called PowerDraw back then, when I used it.

No.  But I've seen a few other CAD programs on the Mac, too, and there's at least a couple that have done 3D drawing (like what Autodesk added to Autocad 2007) for quite some years now.  Easier to use than Autocad, too.

But I suppose I should've added that I need a Civil package.  I'm using Civil-3D these days, so I would find it terribly difficult to use anything that is not model-based.  I've actually been toying with the idea of creating one, a framework-based solution that is true multi-user for EVERYTHING, but it would be a large enough effort that I'd have to start a company in order to manage it.  If Apple ever made their OS run on ANY machine that can run Windows, I'd feel a lot better about tackling the job, since practically the entire industry is using Windows machines, and no one would be very interested in switching to new software if it required trashing their PCs for Macs.  But creating a multi-user CAD program would be quite difficult without being able to leverage EOF, and EOF only exists on Mac OSX these days.  So the effort would be prohibitively difficult on Windows.

[GDF]

I think you can get around this if you can combine all the icons in "acmap.DLL" and "land.DLL" into a single file called "CompanyLand.DLL", but I'm not entirely sure how to do that.

I use ResHacker.exe "Resourse Hacker" to compile my custom dll file of bitmap images for my toolbar. If this is what you are talking about.
This is where I first found the program.      http://www.afralisp.net/

As to using the cui editor...I don't. Even in 2007 I edit the mnu file and compile it using the cui editor (this is the only time I use it). Still works great.
We have our company menu files on the network...and nobody messes with them but me. We figure that if a toolbar or menu pull down item needs
to be added then everone should have access to it. All of my menus have their own dll file containing the toolbar bitmaps. Been doing it this way for
eight years now, and I'm too old to change...

Gary's 2 cents worth