Dump function and symbol lists to determine what apps to implement

[upintheairsheep]

A website, bot, etc should be created to decompile and dump the list of functions, symbols, etc used in a large list of macOS (and later iOS software), and compare the list to what Darling includes now, to pick out unsupported functions and symbols to implement to make the program work. This may speed up the process of supporting GUI software by a huge degree, as opposed to randomly adding functions and symbols.

[HinTak]

Two points: (1) FWIW, I don't think any of the darling people are implementing "interesting" "uncommon" things - there are barely enough time/people for common/necessary things! (2) no need to decompile. It is a very well-known feature of llvm-nm (part of Xcode) to list symbols.

In other words, you don't know what you are talking about...

[upintheairsheep]

A proposed solution for this on the technical side is to use wget to temporarily download a given URL to cache it, process it if necessary (if it is a .dmg, .pkg, .zip, .app.zip, .ipa, etc), run it through llvm-nm and dump it to a text file, get basic info about the executable and package, add it to the database, delete all files related to the processed package, repeat. Support for direct Darwin binary links, DMG-based "move .app to Applications" installer or simple .app in dmg file, PKG installer and .pkg in .dmg, .app.zip files that directly have the .app folder zipped, no .app folder/file in the zip if you get what I mean, .ipa files for iOS/iPadOS apps, and any installer mentioned above or a .app file in a .zip file. Many sources exist for all of these files I have mentioned, but for now, just process every Homebrew formula and cask then we will get into other sources. A public submission area on the main page of the database, or a Discord bot (to prevent spam on a normal API) to submit a link containing an installer or application, or a text file list of direct links containing them should be implemented to give a chance for more obscure items to be added.

[CuriousTommy]

Don't take this the wrong way @upintheairsheep, but the idea of set up an automated system for collecting the symbols is not going to be that helpful.

1. It's just seems like a lot of unnecessary work, when we can just ask the user to provide an nm output.
2. Our productivity is not really going to improve with this additional metadata. We lack manpower, this is only to going to add more work on our plates.

[upintheairsheep]

The only metadata we need is the name, version, and package ID (com.example.example)

[HinTak]

Again, you don't know what's "common". Homebrew is hardly the most common / needed software.

Besides, most of homebrew content works natively and directly on Linux. There is no need to specifically run them indirectly, running the mac version of it on darling on Linux.

If you want "common", try Safari! That's common. And there is no Linux version of Safari, so that's a need.

What is useful is excluding anything from homebrew, as they all work natively on Linux and therefore no need to make the mac os x version of them run on darling on Linux.

[bugaevc]

FWIW, there are definitely web browsers on Linux that are using WebKit (e.g. Epiphany). That's as close to "Safari on Linux" as it gets, short of someday running actual Safari via Darling.