Windows 95 Programs

[Lilliana Adames]

Ifyou read anything about how the Windows installer system works, it's obvious they applied some ideas from transactional databases to program installation and maintenance, not to mention the .msi files themselves are a database.

There is always the question in designing any database - do you want speed or accuracy/safety? Given that installers can modify system configuration and that a mishap could render the system inoperable, safety has been given a priority over speed. One of the reasons why .msi installers are so slow is because rollback files are made for each file, etc. that will be modified, and then deleted afterwards - allowing any changes to be "rolled back" if something goes wrong in the middle of things (such as a power outage or system crash).

Now, I believe the MSI engine itself enforces installing, modifying, or removing only one program at a time - if you try to run an .msi while another is uninstalling, for example, it either won't run or will wait for the currently running uninstall to finish. Non-MSI installers may not behave this way - since they don't use the MSI engine. But because of this safety design decision, this is probably why appwiz.cpl insists on only letting one uninstaller be called at once.

Most uninstallers track what they are changing so they can roll back successfully if there's a failure. If one isn't aware of all the changes being made (by other uninstallers) then it may actually make things WORSE if it tries to roll back a failed install.

Uninstallation tasks frequently modify files that are shared by multiple programs, or system files\the Registry (a partial reason for needing administrative power to do it). If multiple uninstall tasks ran at the same time, they could conflict. If you have ever had a run in with "DLL Hell", it would be the same. Other programs or Windows itself could be left in an inconsistent state.

Uninstalling programs simultaneously, besides having the potential problems other mentioned, have very little benefit: it won't be much faster than uninstalling the programs sequentially. Unintalling a program is a task involving disk IO. Running several programs that do IO isn't faster than running them sequentially (unless the programs are installed on two separate physical disks). In fact, it's likely to be slower because the two competing IO tasks will make the disk cache less efficient and the disk's physical heads will have to jump from place to place.

Hi there! So im trying to make a device that can run VSTs on it and was looking to find any open source code to run it with and i found a website that offers open source code and runs on C++! Exactly what I needed except when trying to download the files it says that the files only run on win32 or 64 etc.

I knnow this might sound like a dumb question but are those files in relation to the device I download them with (i.e. my computer?) or is it referring to the device I run the files with (i.e. my arduino?). And if it is referring to my computer, which is a windows 64 bit, is there any way i can use that open source for my arduino?

I recall hearing a few years ago when Microsoft stopped supporting XP that embedded XP would be still be supported. At the time I know it was used in some brands of ATMs. So it's very likely that there may be some embedded controllers which will run a Windows program, but the catch is they'll need to run Windows first, so that the Windows application will run in Windows. I'd expect a lot of $$$ to be involved to buy such a thing, given the mission-criticality of industrial/commercial real-life applications.

Don't fall into the trap of thinking of Arduino being a C device. The Arduino IDE is programmed in C, but what goes from there to the board is in a format that an Arduino can run. If anyone felt like it, they could devise an Arduino IDE that worked in Fortran or Cobol; the stuff coming out the back would still look like it does from the actual IDE you have right now.

And since the C in an Arduino has a particular (even peculiar?) look and feel ie setup() and loop(), and expects some specifics like digitalWrite() etc, the C from another application is not going to conform. Even if it did, a program written for a PC with memory in the GB range will never fit in a uC with memory in the kB.

The big difference between an Arduino and a Windows PC (which can also be programmed with standard C/C++) is that the Windows PC will have 2GB of RAM and the Uno has 2k and the Windows PC probably runs at 1.6GHz whereas the Uno runs at 16MHz.

The fact that the Arduino IDE simplifies things with setup() and loop() does not mean that an Uno can only use that type of program. Under the hood the Arduino IDE provides the other stuff to make your sketch into a standard C/C++ program.

It's not incorrect at all. C or C++ doesn't go anywhere near the Arduino, so the Arduino is no more a C device than it is Fortran or RPG: it's the IDE that makes the Arduino programmable in C and there could just have easily have been an IDE (and maybe there is) for Basic. That wouldn't make an Arduino a Basic device.

The C in an arduino does not have anything particular nor peculiar. It's plain C and C++ with the limits and capabilities of a micro-controller. Then you can decide or not to use helper functions, libraries etc which are bringing an abstraction layer specific to a board to make the programmers' life simpler (e.g. hadling the Serial port through the Serial class rather than having to do it manually yourself or digitalWrite instead of messing around directly with ports registers)

That being said you are right, somewhat the same could be achieved with other programming language (and natively as long as that language offers direct memory pointers access otherwise for some features you would have to rely on libraries you write in another language such as C, C++ or assembly)

VST plugins need a VST host. And a VST host is going to need a lot more resources than any arduino can provide.

Forget about using an Arduino for anything like this.

You should be looking at either an embedded Windows device, or a linux based device like a raspberry PI.

Raspberry PIs with built in Wifi start at $10 USD.

Currently I'm accessing HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall and reading each of the keys from there to get a list. (I've been told this isn't the proper way of doing things) I've seen examples of using WMI/Win32com to do this as well but have seen comments along with those implementations that WMI might be turned off on certain machines and that it's not a very reliable solution.

Is there a method which is both proper, and reliable to get a list of installed programs? None of the WMI examples I've seen have worked on this machine (hence my reluctance to use it, I'm only running WinFLP; which is a stripped vers of XP.)

I seem to have also found the TechNet article which my searches have turned up which is provided to a similar answer on my question: -us/154dcae0-57a1-4c6e-8f9f-b215904485b7 Note that Vista/7 listed under Platforms very clearly says "Nope"...won't work. So the WMI deal seems like it's a no-go...

Actually, the real weakness of the WMI approach is that it only lists products installed through the Windows Installer. So it's will not give you the full list. Many programs use different installers. Just compare the results between the (Select * from Win32_Product) and what is displayed in the Control Panel. So, unless you are sure that the program that interset you in your listing are installed with MSI, WMI is definitely not an answer.

So it may be not very pythonic, but the best way, as far as I know, is to use the registry as you've done. This is actually how the control panel works, so at least Windows considers it to be the most robust way to do it.

WMI is the correct way to look for installed programs as it will work across different versions of the OS and will be supported going forward. Looking for specific regkeys may work fine for specific versions of Windows but is not guaranteed to work in the future. Here is some simple python code to check for Box Sync which I just tried on Windows 7. Note that not all fields will be available for every product so be aware these will be 'None.'

I have created a custom query for you that pulls all the columns from "programs" table and join all the columns from "os_version" table.

SELECT programs.name, programs.version, programs.install_location, programs.install_source, programs.language, programs.publisher, programs.uninstall_string, programs.install_date, programs.identifying_number,os_version.name AS os_name, os_version.version AS os_version, os_version.build, os_version.platform, os_version.patchFROM programsCROSS JOIN OS_version

Now having a look at the schema, I can't find a table xdr_data, where could I see it?

I have tried to join xdr_data and os_version without success until now.

Thank you again and regards,

Thank you for reaching out.

Let me explain.

We have two places to run the queries:

The first place is in the Data Lake and the next is running the query against a Live Endpoint as seen in the below screenshot.

Now, in the query I shared, we have two tables named "OS_version" and "programs".

These tables are available to include in our query to run only against a Live endpoint.

This can be verifed in the link below where you can get to see all the available tables.

These tables are referred to as OSQuery schema.

Now, to run a query in Sophos Data Lake, we have to choose tables that are available explicitly for Data Lake.

For endpoint data to be fetched from the data lake, we have a very limited number of tables available which can be verified in the below link.

=xdr_schema_docs

And also thank you for your previous explanation. The thing is that I thought that we could query the same schema for Live Endpoint and Data Lake, I was unable to find such an explanation in all the documentation I read (and I think I have read quite a lot).

3a8082e126