Jump to content

Mefistotelis

Members
  • Content Count

    86
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Mefistotelis

  1. Typically, people tend to use 'repo' from Android to make a project from multiple git repos. It's a lot more flexible than submodules. With 'repo', you create a 'manifest' (or multiple manifests) which contain all repositories to be included, with indication on branch and commit to be used. It's intuitive, and anyone who worked with Android already knows how to use it.
  2. Right; sorry, I had attention span only to read a few last posts. From a few projects I looked into, only text files like *.lvproj files seem to be detected. Projects with only VIs in them are not marked as LabVIEW, no matter how much are there or what's the file/project name.
  3. The idea of comparing a quarter instead of full timeline is to have kind of derivative of the use of each language - change in the amount of uses, instead of the total uses. Popularity of LV is on decline for several years now. Whether it's 38th or 51st on a chart isn't going to change much. There are many reasons why that is happening; lack of long-term strategy is visible. There was no reaction to HW engineering being transformed from diagrams into Hardware Description Languages. There was no reaction to major languages giving jurisdiction over specifications to non-profit standardizing
  4. Thanks! That is quite strange that I know exactly how LabVIEW works, but can't properly use it for what it is intended.
  5. Wow.. yes, that seem to work exactly as I expected. Makes a new VI file with given control. Can I make it iterate through all the types and open every possible VI in one run?
  6. I need a group of VI files, each containing only one control on Front Panel. Basically, I want every control available in LV menus in its own separate VI. Is there a way to automate creation of such VIs?
  7. Made CPC2 re-creation - connector pane is now there, but LV seem to not want to display it without BD... While at it, also made a simple icon creation.
  8. Yes. What I didn't mention in the video is - ATM the tool only supports the specific components I put into project. I didn't even looked at other controls yet. And for various flavors of numeric/boolean controls - all we can figure out is whether that's a control or indicator, the specific visual representation of the switch is lost - recovered one always looks the same. Thank you, will consider that. Complex projects are already supported - you just need `find` to list all extracted files, and do the 3 actions for each of them: extract to XML, recover FP, re-create VI.
  9. Oh, going into that is definitely not for 15 minutes video. Recovering it completely and automatically, for every VI - would be a project for several months (considering this is my afternoon project). It's way easier to make partial recovery, requiring the user to finish. And just placing block diagram with the components we've already recovered for FP - is trivial. Yeah, noticed that as well.. the whole connectors pane is very easy to handle, I will likely fix that in the nearby future. Yes. That is probably the main use of that solution - recover the project without Block Dia
  10. I sorted all the extracted LV14 files by size, and one stands out. Size of Block Diagram in XML form: 15MB And the size is not due to some binary blob stored inside - no, the is just a lot of parts in the block diagram heap. Amount of XML tags: # xmllint --xpath "count(//*)" ex_allChanPropsMod_BDHb.xml 234903 File: vi.lib/Platform/express/ex_EditUserDefinedProperties/ex_allChanPropsMod.vi And its content isn't even that impressive: There are just a lot of cases hiding in the "Case Structure", and a lot of copies of the same chunk of diagram within each cas
  11. Yes. "&lt;" and "&gt;" are just symbols used to allow storage in XML; these are so-called HTML Entities. So this string really is "<vilib>". No idea. There are more tags which can be used, but I never cared for listing them, or checking whether they're all hard-coded. EDIT: Reading @Rolf Kalbermatter answer above, I see he already answered this.
  12. Yes. Extract your file, and paths will be in XML. "LVPath" is actually a class, which is instantiated for many things. So all paths basically have the same structure. I export it to XML as list of strings - this is how it is really stored. Elements in the list are either normal strings, or tags which LV replaces with value from current config. Example: <LIvi> <!-- LinkObj Refs for VI --> <Section Index="0" Format="inline"> <LVIN Unk1="NI_InternetTK_Common_VIs.lvlib:Close Calling VI's Windows.vi" Unk2=""> <!-- VI To Lib Object Re
  13. Thanks @Rolf Kalbermatter, did proper update. Watcom actually had Windows extender, separate to the DOS extender. Also, interesting prediction. Personally, I think Apple overestimates scalability of their phone silicon. But we'll see.
  14. What you want is to flush your output file occasionally. File writes are buffered, and performed only when enough data has gathered, or the file is being closed. In C, flushing is done by fflush(); for LV - someone else will have to answer.
  15. Thank you! That added some important info to my list: https://github.com/mefistotelis/pylabview/blob/master/LVcode.py#L224 A little below the arch list, there's getVICodeProcName() function where I added mangled names for the dispatch table items which I got from LV for MacOS. Pylabview will now, upon extraction of a VI file, create a MAP file with offsets and names of known symbols within the executable bytecode.
  16. Do we have a full list of these architectures somewhere? I've seen: 'i386', 'wx64', 'ux86', 'ux64', 'm386', 'mx64', 'PWNT', 'axwn', 'axlx', 'axdu', 'ARM ' (those are all little endians) I'm not exactly sure what each of these means. Are different OSes counted as separate architectures?
  17. I just did. Wow. Now I know I was missing a lot by ignoring Apple. At least from this perspective. Not a single function name is missing, and all names are decorated with types.
  18. Yes, that's the table. Surprisingly, it's not just written directly as an array, but instead there's an init function which fills it. Sounds a bit unnecessary. And introduces possible security issues. I hope the function is verified before execution, and executed later than when the VI is opened. Otherwise the ease of modification might be an issue. Besides modifying it, you may just want to look at it, to either debug an issue within LV, or just check how the code works. With the declarations and all structs defined, you could also turn the VI code into COFF; that would
  19. Do we have declarations of these callbacks? Ie. here's one: void __cdecl _InitCodePtrsProc(struct VICodePtrsRec **viCodePtrs); Just to explain what I'm talking about: * VI files and other RSRC files, can contain compiled code stored in VICD resource * VICD consists of the actual assembly, and list of 'patches'; these patches combine function of imports table and relocation table * The actual assembly always has a InitCodePtrsProc() function, which sole purpose is to fill an array of code pointers which it receives as parameter * The code pointers are just refe
  20. The options are actually in two places: some are in the LV executable, but most are in RSC files within LV folder. The executable you can open with any RE tool, like Ghidra, or Ida Pro. You could also use 'strings' command to list all text chunks from executable, and guess which of these are ini options. The RSC file you can extract using pylabview, and then you get a list of tokens in XML form, ie. there's part of lvapp.xml: <Section Index="11400" Name="ConfigTokenStrings" Int5="0x00000000" Format="inline"> <String>tmpdir</String>
  21. The worst, but really really rare case, would be for the tool to create damaged binary. But I'm doing a lot of checks to avoid that. And you already stumbled upon some of the checks: The tool does a lot of checks and raises exceptions if anything looks out of the ordinary. The exceptions are then captured and the block which raised them is exported as a binary file, without trying to make it XML. In case of VICD you'll actually always see this, as I didn't published parsing of the data. This means the VICD will just always stay as binary. If you want to be sure the data is identic
  22. Well, that's really against what I want to achieve.. my idea is to extract everything to XML and allow users to do all the modifications in XML form. Then you can easily re-create the VI. Note that the re-created VI will, in most cases, be identical to the original (there are few exceptions, as LV uses multiple threads to save the file and is generating names section in pseudo-random order as a result, and in older versions of LV even the section data is ordered randomly). The password option is the only exception to that rule, and I'm thinking about removing it completely. It's untested
  23. @dadreamer if you're often looking at the binary data, you might have some use of "print-map" function of my readRSRC script: ./readRSRC.py --print-map=RSRC -x -i 'test_out/lv10/vi.lib/Utility/Convert RTD Reading (waveform).vi' test_out/lv10/vi.lib/Utility/Convert RTD Reading (waveform).vi: Warning: Block b'PRT ' section 0 size is 152 and does not match parsed size 128 test_out/lv10/vi.lib/Utility/Convert RTD Reading (waveform).vi: Warning: Block b'VICD' section 0 XML export exception: The block is only partially exported as XML. 00000000: RSRCHeader[0] (size:32) 00000020: BlockData (size:
  24. You can edit that wiki if you have more info. or write your comments in "Discussion" page if you're unsure about editing it directly. I created a whole category of articles there: https://labviewwiki.org/wiki/Category:LabVIEW_internals
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.