LabVIEW's "hidden" decoration styles

[Steen Schmidt]

NI doesn't make the law. (That would be silly.) Say I created a game, and I put in the license agreement that you weren't allowed to make mods for it. (For the record, I would never actually do that, as you may have guessed.) Someone made a mod for it anyway. Now if they were selling it, maybe even giving it away for free, I might be able to claim they're violating my copyright. (Without copyright law, software licensing is meaningless.) If they just modified the software on their own computer and played it like that, I wouldn't be affected in any way.

 

Doesn't it sound funny in your own ears: License agreement, and then breaking that agreement? Why do you think it's up to you to decide which parts of the agreement to follow and not to follow? That is the main point, I think, that irks us on this board; that you display such indifference to violating a contract that you have signed. I would never hire a guy like you, if I found such statements as yours on the internet. I simply wouldn't trust that you would honor any agreement that we made.

 

Sure, software licensing is up for a major change over the comming years. That probably goes for large parts of the digital media usage legislation. But until that happens you have an agreement with your software vendor, no matter if you have paid for that software or it's free.

 

One of the much talked about things currently is if you actually have the right to resell "used" software. My opinion is that you should be allowed to, but many software vendors disagree. Several large companies are in the process of changing their licensing schemes so you lease their software for a limited time (20 years for instance), in which case you definetely cannot transfer your contract to a third party.

 

So, probably nothing bad will happen if you don't tell anyone what you do, but it's definetely a problem if you involve others. And even if you keep it exclusively to yourself it's still a violation, it's just not one with a high risk of getting spotted by anyone.

 

I know cars are overused in analogies, but if I buy a car, and the manufacturer of the car says in the manual I'm not allowed to modify their copyrighted design by painting it another color, I can still do so. It's still my car. If the manufacturer goes that route with the copyright, they might be able to prevent me from then selling my car, but otherwise I can modify my car however I want. (as long as it's not violating any laws that would exist anyway.)

 

Anybody can put anything into a contract as long as it's not violating any other law, and if you sign that contract (for instance when buying a car) it's binding. Using your analogy; Porsche had a very special paintjob on a very small number of 911s a year or two back, where they put in the buyer's contract that they were never allowed to repaint the car, and any damages to the paint should always be taken to the Porsche factory for repair. Nobody else are allowed to touch up that paintjob. That's a legal contract, and I expect those select Porsche owners are thrilled by owning such a special car .

 

As long as there's no damages, I fail to see how any legal action could be possible.

 

You break a contract. Contracts (your trustworthyness basically) and money are two things that glue the world together. It's taken very seriously when you mess with either.

 

And damages? One could think up a number of possible damaging outcomes from you looking at source code you agreed not to look at for instance; You could get technical inspiration that made you rich in a couple of years - you could even turn out to become that software vendor's biggest competitor in the market. It could be even worse than that. A slight mention of how to break a licensing scheme (just wisper "MD5" and "Calypso algorithm" in the wrong forum) could potentially mean that some poor sole sold 5 instead of 5,000,000 licenses of his or her software. There are many many real world cases that supports this statement; Nero Multimedia, Winzip, Ghisler (makers of Total Commander), and IDM (makers of UltraEdit) for instance.

 

/Steen

[viSci]

I would definitely consider hiring a guy like Flarn.  

Many moons ago scripting was taboo too.  That did not stop

some of the more intrepid LV'ers from using it and proving to NI

that it should be a released interface.

[Rolf Kalbermatter]

I would definitely consider hiring a guy like Flarn.  

Many moons ago scripting was taboo too.  That did not stop

some of the more intrepid LV'ers from using it and proving to NI

that it should be a released interface.

 

Scripting wasn't taboo, just hidden. While one could argue that adding an undocumented INI key to a configuration file might be already a violation according to the DMCA, breaking a password protection that is not super trivial to guess, definitely is and could be taken to court. Heck as I understand DMCA, doing anything that the software vendor simply has said "Don't do it!" is already a violation. And NI didn't make the DMCA so it is indeed not them who make the law. Nevertheless the law is there for them to use, only in the case of the VI password website it does not fall under the DMCA, but Germany has also some laws that go into that direction.

 

I have a feeling that the only reason NI hasn't really done to much about this so far, is that they didn't think forcing a lawsuit after the fact is doing much good, both in terms of damage control as well as being the big bad guy going after a poor user. I'm sure they would have much less hesitation to go after a corporation trying to use this in any way and most likely have done so in the past already.

[Steen Schmidt]

Lucky for him then .

 

There is a big difference between using a hidden feature at your own risk that didn't violate any license agreement, and breaking a feature that could potentially invalidate the code security of NI's customers.

 

But it doesn't upset me that much that flarn2006 wishes to look into how stuff like password protection is implemented, and maybe trying to defeat it. H***, all us techheads here probably have that urge in us, and we have done it in some form or another once in a while. We just have to look at how this or that works. Yes, that's an appealing trait. But it comes with a big responsibility, and that is where I feel the chain comes of. flarn2006 (what's your name really, I'd like to be able to call you something more human-like ) doesn't acknowledge this responsibility. Now he has asked in a couple of different threads if it's OK or not to tell people how to defeat the password protection. He seems to genuinely believe it is up to himself to decide which parts of a license agreement he may break, and he can judge all by himself that this is a feature that nobody but NI wants.

 

I think the password protection scheme is a big deal. It can be broken, it's not that hard. I've seen it done numerous times over the years, it's not rocket science, so there's nothing to prove here. Only a skewed morale. If some of my (commercial) code ends up in his hands, I'll expect him to attempt to break into it, and I'll expect him to feel righteous doing it. But I'd be feeling robbed. So no, I wouldn't hire him, but I'd keep him real close if he was in my circles...

 

He's by his own account only 19, so he can still change his views of course. Or he could be the one writing the next trojan that kills my backup servers...

 

/Steen

...some poor sole...

 

Did I really write "sole"? . Don't feet the trolls I must add then...

 

/Steen

[dadreamer]

On 1/21/2013 at 3:48 PM, Rolf Kalbermatter said:

The LabVIEW picc format resembles the Macintosh PICT format in many things, but has a somewhat different binary data format.

Have seen this statement of yours many times, but still don't see how you came to this conclusion. I investigated those built-in PICCs a bit. The "Cosm" resource forks in lvobject.rsc (labview.rsc in the old versions) don't contain any graphic operators. For example, this is how the Flat Box resource looks:

0000 0003 //cosmetic flags
0000 0000
00F0 0000
FFF0 FFF0 //rect
0010 0010
0000 0000
0200 0000 //symbolic color
0000 0000
0000 000B //image index to get later (e.g., 3D5)

Now, this 0xB is just an index to the LabVIEW's internal structure, that can easily be observed in Heap Peek.

Not very informative though. Here's the handler procedure address and some data, passed to it. Obviously not enough to do the drawing. This kPiccImage has 0x3D5 number assigned as well, which just indexes into the LabVIEW's internal table, looking like this:

I marked the Flat Box line. Only two fields are here: the handler proc offset and the data, being passed into it. The data is in fact nothing more than the graphic attributes for the handler to draw, like the border width and the line style. Let's check this. I set the border width to 5 (instead of 1) and the line style to 0x11 (instead of 0x44).

Easy to see:

- Those PICCs are used in many places of the LV GUI.

- Almost all the drawing work is done by the handler proc.

- The procs and the attributes for the decorations/cosmetics are hard-coded inside LabVIEW.

The proc itself uses the Drawing Manager functions to do the work. So, if it's the Flat Circle proc (to simplify), it behaves this way: DEmptyRect -> DSelectNormPen -> DPaintOval -> DSelectNormPen -> DFrameOval. It could easily be reproduced on the diagram:

Draw Oval.vi

The left circle is drawn from the diagram, the right one is a built-in decoration. Of course, it needs more work, when applied to a real project, as redrawing is necessary, when the window is resized, minimized, overlapped etc. The handler proc takes this job for the native cosmetics.

So, I did not find anything that would resemble the Mac OS PICT format (version 2 or 1, at least). It is more like a "Picture in C" instead, as someone noticed earlier.

[Rolf Kalbermatter]

There is potentially a mixup somewhere with namings. It's a long long time ago that I looked at this and I'm not sure about the exact format of a PICC at this time. LabVIEW also has something that it calls pixmaps (and is in fact the Picture Control data format which has opcodes and parameters as can be seen when looking at the Picture Control VIs). It may technically not be the same as the PICC resource format, but I'm really not sure at this point and don't feel like doing that sort of archeology at this moment. There are in fact several different formats in LabVIEW for graphics. Some are LabVIEW native, some are bridges to platform specific formats. Some are pixel based and others are more vector based.

And if I had access to the source code of LabVIEW I would first fix some annoying bugs and shortcomings before looking at that sort of things.

Edited January 13, 2023 by Rolf Kalbermatter

[X___]

Someone gives Rolf access to the source code, pretty please?

[dadreamer]

On 1/13/2023 at 3:40 PM, Rolf Kalbermatter said:

LabVIEW also has something that it calls pixmaps (and is in fact the Picture Control data format which has opcodes and parameters as can be seen when looking at the Picture Control VIs).

Yes, looks much like you meant the 2D Picture pixmaps opcodes. Their names are similar to those from the QuickDraw PICT Opcodes document (e.g., frameArc, paintArc), but the values are different.

On 1/13/2023 at 3:40 PM, Rolf Kalbermatter said:

Some are LabVIEW native, some are bridges to platform specific formats.

On classic Mac OS I've seen the following. If a vector PICT image (of kLVPictImage type) is placed onto the panel and resized, it is redrawn as if it was a LV native kPiccImage. But when the VI is moved onto another platform, such as Windows, the image becomes a common bitmap, losing all its vector abilities. Seems, the presence of a platform-dependent API (such as QuickDraw) really matters.

On 1/13/2023 at 3:40 PM, Rolf Kalbermatter said:

And if I had access to the source code of LabVIEW I would first fix some annoying bugs and shortcomings before looking at that sort of things.

I'd add dynamic (un)registration of the drawing procedures for the cosmetics. It would allow to add custom decorations relatively easy, even though the Drawing Manager is undocumented to use in the DLLs. Currently no way to add the user decor, not having LV sources. But honestly all this legacy tech should be rewritten or even removed/replaced by something much better. EMF/WMF support is not that good and SVG is still not considered. 😿

 

By the way. This thread seems incomplete after @flarn2006posted in his profile some info to obtain all the decorations from lvobject.rsc. Here's the VI to do that: All Cosmetics.viChoose the .mnu path on the FP, run this VI, then import the subpalette in the standard way (Tools -> Advanced -> Edit Palette Set).

Most of "hidden" elements are not that interesting as they're of no use as stand-alone decorations. Some could be useful tho, like those DSC module graphics (valves, pipes etc.), except for the Multi-Segment Pipe, maybe, because it's not functional as a decor. Or how about some cool gradient decors?

[bjustice]

Bumping this thread:
Is it possible to get a working copy of the VI that @flarn2006 originally posted here?
I'd really like to be able to get access to a right angle triangle decoration.

[dadreamer]

Seems like NI has changed the indexing scheme in some version. For example, in LabVIEW 2011 32-bit Flat Right Triangle image is at 0xFF910460, but in LabVIEW 2022 32-bit it's at 0x43A. Moreover, those high contrast extra decorations, that@flarn2006discovered, are not sticky on the VI save - LabVIEW reverts them to the regular squares (just tested).

Edited June 24, 2023 by dadreamer

[bjustice]

yarr, thanks for looking.  Appreciated.

I recognize that I could probably just go and do things in a proper photoshop editor like GIMP, but sometimes it's just easier to make quick little custom graphics in LabVIEW using LabVIEW decorations.  The decorations are then easy to color and tweak without having to go back into photoshop editor.  However, even having something as simple as right angle triangles or half/semi-circles would go a long way towards making so much easier to make more complex looking-things in LabVIEW with decorations.  So, if anyone has happened to figure out how to make those types of decorations, I'd be pretty stoked.

For reference, here's a fun example of a thing that I made in LabVIEW using only decorations.
I ran into 2 major frustrations:
- Lack of right angle triangles means that you have to get tricky with squares and normal triangles to get the same effect
- Lack of semi-circles means that I had to use a full-circle for the mouse, and then overlap it with a black square.  

you can see that it was a bit convoluted and annoying to make the little key icons without right angle triangles:

decoration fun.vi

[dadreamer]

Okay, it's relatively easy to get access to those extra decorations. In modern LabVIEW's they start at 986 (0x3DA) and then, when you increment the index, you go through the columns from top to bottom, looking at@flarn2006's picture in the very first post of this thread. To find the memory address of the image index, you may use any debugger or helper tool of your choice, like CheatEngine or ArtMoney etc. In Heap Peek you can get the address of the decoration object and the image index assigned to it. Then in CheatEngine/ArtMoney search for that index and pick up the nearest higher address. Now you may alter the value at that address and watch how the decor is changing on the panel.

In fact,@flarn2006discovered not extra images, but extra handler procedures, that perform the drawing with the Drawing Manager API. It looks like LabVIEW has many of them reserved for some purpose. Or maybe they're just leftovers of the early versions. Indeed, some of them could be useful in real applications. But I still don't see how a modified decoration could survive the save without hooking into LabVIEW internals at least.

Seems, like it works! Here's the VI with the most decorations from the first post: Extra Decor.vi

And if anyone wants to recreate the VI, here's the script that I used: Adding Objects (Extra Decor).vi Not guaranteed to behave well on anything different than LV 2022. Also requires a couple of SubVIs from here.

Edited June 24, 2023 by dadreamer

[bjustice]

This is awesome, thank you for the info as well

[Zou]

On 6/23/2023 at 2:57 PM, bjustice said:

Lack of semi-circles means that I had to use a full-circle for the mouse, and then overlap it with a black square. 

You can get a semi-circle from the Classic Tank.

 

[bjustice]

2 hours ago, Zou said:

You can get a semi-circle from the Classic Tank.

 

I had no idea what you were suggesting here until it clicked for me.

The semi-circle decoration that daddreamer found apprears to be the exact same decoration used on the classic tank control.
If you edit the classic tank control, then you are able to copy/paste the semi-circle onto your front panel and it then becomes a color-able decoration.
I wasn't aware that it was possible to "steal" decorations from control like that.  Neat

[bjustice]

I created the following VI for myself, but re-sharing here to be helpful.
I've aggregated all the controls/decorations into a single file, which acts as a bit of a large palette.
Some of the DSC controls are super cool.  They're not just vector resizing, but procedurally resized.  The segmented pipe control, in particular, feels like a really cool tech demo for what the PICC format/LabVIEW can do.
Makes me really wish we were able to make our own.

• DSC toolkit controls (taken from another NI forum post - so I assume it's ok to be sharing these across the forums?)
• DSC toolkit hidden controls (Some of these were included with DSC, but not placed on the palette.  Not sure why.)
• All the decorations that dadreamer collected
• All the decorations from the modern/silver palettes

All decorations.vi

[Lipko]

Thats very nice, thank you!

(there a typo: 3D valves should be 2D valves.)

[Zou]

On 6/26/2023 at 9:23 PM, bjustice said:

I created the following VI for myself, but re-sharing here to be helpful.

Could you save it to LabVIEW 2018?

Thanks.

[bjustice]

11 minutes ago, Zou said:

Could you save it to LabVIEW 2018?

Thanks.

2018.  also fixed the typo

All decorations.vi

[Zou]

Thanks.  But there are many other components you can "Steal" from NI ctrls.

For example, the 3-D semi-circles from the Modern thermometer ctrl.

In addition to replace an existing component, you can add extra components to a ctrl as long as you can set the component to be slave of the housing/frame.

 

Untitled 2.vi

[Lipko]

Loosely related: is it possible with some hack to copypaste more decorations to a boolen control true or false state?

[Rolf Kalbermatter]

51 minutes ago, Lipko said:

Loosely related: is it possible with some hack to copypaste more decorations to a boolen control true or false state?

More than one per state? No.

[Lipko]

1 hour ago, Rolf Kalbermatter said:

More than one per state? No.

Sad.

But: if you have a picture control and draw stuff in it, export the image as .emf to clipboard, then import it to the control state, it works. The image is vector image, so it will look good when printing.

[Zou]

On 6/29/2023 at 3:20 AM, Rolf Kalbermatter said:

More than one per state? No.

That's not accurate.

It's more like this:

- All states looks different decor:       1 decor,

- True state has decor, False state has no decor:    1 decor,

- All states looks same decor: as many as you want.

 

2 decors.ctl

Edited August 16, 2023 by Zou
Add ctl and images