32bit Hkx File Detected

[Barton Ostby]

HiI'm just posting this as an observation. Both my pi2 and zero2w get detected as Armv6 when running the 32bit Raspberry Pi OS, even though they support ArmV7. I'm not sure what happens on a pi3/4/5.

I believe the v6 install script detects the architecture on 32bit builds by running readelf -A /usr/bin/sh

That's why I posted the output.

Although there's a check in the script for detecting Armv7m it seems like currently that won't get triggered - at least on Raspberry Pi OS.

Some thoughts:

I could be wrong (maybe different on Debian?).

It might not matter.

You could change the detection method.

The script could be left as is - in case the foundation start to supply/target Armv7 builds.

You could stop building/maintaining the Armv7 binary if not needed.

Apologies again if this comes across as entitled or argumentative - it's not meant that way at all. It was just something I noticed while poking around. There's no real issue here just an observation.

The current method is not detecting the processor itself but indeed checking other binaries on the system (sh to be precise) and downloading an FTL flavor compiled for the same target architecture your local sh binary has been compiled for. So the reason for armv6 being picked for all Raspbian images is their "laziness" to provide only a single "one-fits-all" image for all 32bit SBCs.

I'm kind of hesitant to change this for the exact same reasons. Even if we detect v7 using lscpu or other means, their output may be wrong in virtualized environments. On the other hand, the strategy "simply pick what we find as working elsewhere the OS" seems pretty robust.

We're always open for new input and I'd be more than happy to start a discussion about potential optimizations. At the same time I want to mention that it'd be tough to anticipate the likeliness of a failure of a new detection scheme given the multitude of virtualization providers out there. We already know it's not easy.

I have a test stand and labview system that is largely using standard templates to run. I had to convert all my VIs from 32 bit to 64 bit to solve another issue and now my Standard User Interface no longer launches my process model. I've attached the part of the code where i think the issue may lie and can provide any info requested. Before the conversion, this code would start the process model, prompting a user for part number, etc, before loading sequence files.

If you are configuring LabVIEW as Development Environment, irrespective of 32bit/64bit TestStand will execute without issues, But in Runtime environment both LabVIEW and TestStand should maintain same bit (if LabVIEW is 64 bit then TestStand also should be in 64bit , vice versa)

I downloaded the FTB (Feat The Beast) launcher, and installed FTB Infinity Evolved. The launcher detects 32 bit java but i have a 64 bit computer, and pretty sure that i downloaded the 64 java version. I can't allocate more memory because my pc is "32bit" (Says the launcher). When i press "Run" to play the game, it won't launch and i can see a fail message in the console. I got windows 10 64 bit. The launcher version is v1.4.12. Java version is 8 (recommend)

I did solve this regardless of seeing the plugin.set file. By Uninstalling the IKMultimedia T-Racks Plugins

Installed the 32bit versions only

Launched and forced Plugin search W7 being 32bit found them.

Then went back to install the 64bit versions for Nuendo 5.5 64bit purposes

My 32bit WL version is still working and installed with all my plugin groups successfully, so workflow is somewhat unimpeded. The 64bit version had me intrigued moving forward towards a 64bit plugin only setup

Am I to assume that 32bit versions on plugins e.g UAD-1 or UAD-2 cannot be used by the 64bit version?

Seems like a few 64bit plugins are recognized by WL 64bit, but not all like in Nuendo 5.5.2 64bit

Wavelab 7.2.1 build600 32bit and 64bit version seems to have to lost the links to many previously found plugins

Eg UAD plugins and T RACKS plugins,

These two specific plugins title are my main usage Plugins in Wavelab. I really need to have Wavelab find show them in the Plugin list and get Mastering again

Any idea why VST3 32 bit builds are not recognized by host (Reaper or FL studio), trying the demos they build successfully however the same problem, must I compile them using a 32bit VM? The host simply does not detect the builds, 64 bits works fine. Anyone successfully builds and imports 32bit version of vst3 for windows?

I have not tried debugging in REAPER, I usually use FL Studio for this purpose, since it loads faster than all DAWs. Breakpoints always work, however, in some VST3 breakpoints set in the first line of the constructor of the main class of the plugin do not work, giving an error window in the DAW. And the problem here is not with caching, since the same plugin, built on the basis of a well-known working template, stops perfectly at the breakpoint in the same position. The problem lies most likely in the VST3 interface.

I built a small application 23MB to query several databases using fireDac (Oracle, SQL Server, MySQL, Interbase, Firebird and PostgreSQL for now, I might add support for other engine).

The application checks if there's an update and notifies the users. The first check is done after 5 minutes.

No database connection is done at startup.

The application is available in 32 and 64bit

I'm doing some pre-public release with some friends. I'm sending them the 32bit version (compiled with Release, no debug, no madexcept, all default release options).

I'm connecting to his computer using remote desktop, and I'm copying form my machine to his (Copy/Paste). Both are running Windows 10 Pro with latest updates.

When the application is ran the first time, windows defender pops a screen notifying the user some actions are taken to prevent infection. The program opens, runs ( we can actually connect to database and runs some queries), and closes normally.

The application won't run a second time. Windows pops a screen saying the application contains a virus, and shortly after, the application is deleted (quarantined).

Well, for the fun I send the 64bit version release, no debug, no madexpects all default features. Copied the same way (via RDP copy/paste ) and the program ran smoothly. Windows defender didn't detect a thing. And my friend connected to the databases he have and tested the program for hours without any problem. Closed and Reopened it several times without any problems.

I recompiled the 32bit version in debug mode (over 72MB executable). Copied the same way and windows defender didn't detect anything. Again running for hours, querying against several databases...

I start changing some of the default Release options, and after setting [Runtime errors -> I/O checking] = false the 32bit version behaved as expected.

I uploaded every version compiled in my machine to virus total and nothing was detected. (even the 32bit version windows defender didn't like)

I uploaded every version copied to my friend machine to virus total and nothing was detected.

So I can assume is a false positive... but that is a nasty Trojan!!

This is why I started this post with the context. Since It connects to databases and checks for updates some antivirus might confuse those connections as "trojan invasion". But, as I said, no communication is done at start-time.

just a note when signing files - it may be obvious, but also ensure that any relevant metadata in versioninfo matches the digital signature. e.g. don't use an abbreviation in one place and not the other....the AV guys like metadata to match exactly. Most vendors have a url where you can upload a sample for review where upon acceptance the app will be whitelisted. It is annoying to have to do this however.

I have the false positives kicking in while I'm writing unit tests from time to time. the test app gets deleted before it has a chance to run. ;( And then making what may be a seemingly irrelevant change gets it to work again.

I purchased my certificate and I'm waiting for the validation process to end. Hopefully next week I'll be up and running.

Now I'm worried. I was hopping to solve this false positive issue.

I don't know if this helps, but I'm able to duplicate this virus detection in my machine too. Just by setting the "I/O Checking" to true or false makes Windows defender act.

I set my project file as an exclusion folder to avoid having conflicts between the AV and the IDE. Once I copied my application to another folder and ran it, windows defender quarantined it. The detail here is "ran it". There's nothing detected in the application upon copying it. When it is executed the I/O checking code triggers something that Windows Defender don't like.

Would it do any good to send this application to Microsoft "as is" before I make some changes and Defender stops detecting it?

(Or send it to Emb? They might be able to check the code generated by I/O Checking in this case, and who knows make some changes in RTL or the Compiler? (One can dream, right?) )

This application, cKwel - Query tool, is a SQL helper meant for developers and will be freeware.

I'm just waiting to sign it before uploading and make it publicly available.

(Although it would be really nice to let people download a program that's not detected as a malware )

3a8082e126