Discussion on the feasibility of the project

[KweezyCode]

I would like to ask a question about the feasibility of the project. I've been following this project for quite a while (about 4 years), sometimes going back to check on changes. And I'm honestly disappointed with the result. I don't want to offend the author or those who support this project, but definitely need to change the approach, as adding manual support for each individual application is just ridiculous. A more universal solution is needed. I would like to hear the author's opinion and find out where I am wrong.

(I believe that such solutions, shown in the screenshot, just slow down the project and must be removed or changed)

[ptitSeb]

Well, the wrapping is the root of box64,. So, the wrapping is here to stay. I'm unsure how your screenshot "slow down" the project? What kind of "Slow down" are you refering to?

[KweezyCode]

Well, the wrapping is the root of box64,. So, the wrapping is here to stay. I'm unsure how your screenshot "slow down" the project? What kind of "Slow down" are you refering to?

what I see in the screenshot is a crutch. I believe that such solutions are not universal and do not help in any way to improve stability

[ptitSeb]

This file is generated automaticaly, and never used by dev. I'm unsure why you see that as an issue.

[fish4terrisa-MSDSM]

In my opinion, I think what @KweezyCode actually means is that box64 is currrently focusing on supporting specific softwares(for example, focusing on wine, or even for some particular games...etc.), and it doesn't focus on just implementing more instructions(which, @KweezyCode notes as universal solution for all softwares)

[KweezyCode]

This file is generated automaticaly, and never used by dev. I'm unsure why you see that as an issue.

I gave this file as an example because it is in the source code of the project, but since you said that the file is "never used by dev", then ok. But when I started this issue, I did not intend to discuss individual files, but to discuss the overall operability of the project. At the moment there are over 400 open issues, many of which have been open for years. Most of the software over the long period of box64 development still works unstably

[ptitSeb]

How can you say it "still works unstably" by just looking at tickets? That seems unfair, and probably not the full picture of the stability.

[fish4terrisa-MSDSM]

In my opinion, I think what @KweezyCode actually means is that box64 is currrently focusing on supporting specific softwares(for example, focusing on wine, or even for some particular games...etc.), and it doesn't focus on just implementing more instructions(which, @KweezyCode notes as universal solution for all softwares)

But, what @KweezyCode failed to noticed is that although the patches are maded for wine or some another software, that just doesn't means that only this software benefits from this patches -- actually it benefits all softwares which are related with this patch.

And, adding manual support for each individual application is not as ridiculous as it seems. That's because the users mainly uses box64 to run softwares fall to the below three kinds:

• Close source softwares: Many of them are only available for x86-64, and that makes them unavailable for arm and riscv users. But unlike open source softwares, close source softwares increases in a much slower rate, and there are just a few of close source softwares that doesn't have an open source alternative -- but only a bit of them are important, and the amount of unreplaceable close source softwares won't increase in an unacceptable rate.
• Windows softwares: Now many users use box64 just for wine to run windows programs on linux, and we should notice that most of these programs are games, and games and programs for windows are often bulit upon certain SDKs(especially for games), that means if box64 add the support for one SDK(for example, unity), then large amount of programs will be supported.
• Outdated or seldom updated open source softwares: It's true that some of the users(Including me :-) are using box86/box64 just to run some of the abandoned open source softwares on arm devices. Yes, the source is open source licensed and available, but what's annoying is that the original developer is using much of x86 or amd64 asm, which making porting these softwares a nightmire. So a possible and efficient solution is running these softwares with box86/box64, but usually the amount of this kind of softwares won't increase.

So is not that impossible for us to improve the support for each softwares the users needed. (That's just my own opinion, through...)

[fish4terrisa-MSDSM]

This file is generated automaticaly, and never used by dev. I'm unsure why you see that as an issue.

I gave this file as an example because it is in the source code of the project, but since you said that the file is "never used by dev", then ok. But when I started this issue, I did not intend to discuss individual files, but to discuss the overall operability of the project. At the moment there are over 400 open issues, many of which have been open for years. Most of the software over the long period of box64 development still works unstably

Maybe what you ignored is that currently 480 issues are also marked as closed? Most of them means that a problem is solved and box64 is becoming more stable?

[KweezyCode]

But, what @KweezyCode failed to noticed is that although the patches are maded for wine

i have not checked wine, so it could be true that wine works fine with box64, but i think that README should be updated then.

Maybe what you ignored is that currently 480 issues are also marked as closed? Most of them means that a problem is solved and box64 is becoming more stable?

I think it's also worth looking at the open-to-closed ratio. that's also an important indicator

[KweezyCode]

In my opinion, I think what @KweezyCode actually means is that box64 is currrently focusing on supporting specific softwares(for example, focusing on wine, or even for some particular games...etc.), and it doesn't focus on just implementing more instructions(which, @KweezyCode notes as universal solution for all softwares)

yea, you are close to my point

[ptitSeb]

But, what @KweezyCode failed to noticed is that although the patches are maded for wine

i have not checked wine, so it could be true that wine works fine with box64, but i think that README should be updated then.

Oh, the README is outdated or misleading?

[fish4terrisa-MSDSM]

I think it's also worth looking at the open-to-closed ratio. that's also an important indicator

I think the open-to-closed ratio doesn't really shows the projects' current state, some of the issues are kept in an opened state just because that the author doesn't make a new try of the program with the newest box64, so we just cannot find out whether the problems are solved(And, it's impossible for the developers to waste time on checking whether the program asked for in these issues is working now and deciding whether these issues should be marked as closed...That's just at a really high time cost...

[fish4terrisa-MSDSM]

But, what @KweezyCode failed to noticed is that although the patches are maded for wine

i have not checked wine, so it could be true that wine works fine with box64, but i think that README should be updated then.

Oh, the README is outdated or misleading?

Maybe we should mention in the README that wine is not something that might come later, but something partly usable with box64?

[ptitSeb]

But, what @KweezyCode failed to noticed is that although the patches are maded for wine

i have not checked wine, so it could be true that wine works fine with box64, but i think that README should be updated then.

Oh, the README is outdated or misleading?

Maybe we should mention in the README that wine is not something that might come later, but something partly usable with box64?

Oh, well, the point on wine is that: if you use the regular version of wine, it needs box86 also to run. But if you use a version with Wow64 (but it's still experimental), box64 alone is enough and it works great. The solution, later, will be the "box32" option of box64, but it's not working yet. I'll try to rephrase the wine part of the README soon.

[fish4terrisa-MSDSM]

Oh, well, the point on wine is that: if you use the regular version of wine, it needs box86 also to run. But if you use a version with Wow64 (but it's still experimental), box64 alone is enough and it works great. The solution, later, will be the "box32" option of box64, but it's not working yet. I'll try to rephrase the wine part of the README soon.

Box32? That will be great! I'm really looking forward for that, as some distros, for example ArchLinux ARM, doesn't have a multilib support and that made it hard to run i386 binaries on arm64 system.

[ptitSeb]

Oh, well, the point on wine is that: if you use the regular version of wine, it needs box86 also to run. But if you use a version with Wow64 (but it's still experimental), box64 alone is enough and it works great. The solution, later, will be the "box32" option of box64, but it's not working yet. I'll try to rephrase the wine part of the README soon.

Box32? That will be great! I'm really looking forward for that, as some distros, for example ArchLinux ARM, doesn't have a multilib support and that made it hard to run i386 binaries on arm64 system.

Box32 is the current focus of my dev. effort... Some Linux games are working (like Anomaly Warzone Earth, Waking Mars, PixelJunk Shooter), and some other are working but still a bit unstable (The Stanley Parable and The Witcher 2). I'm working to have wine running on it, but it's there yet...