On Mon Mar 3 11:37:25 2025 +0000, Edward OC wrote:
@iamahuman , first person to say thank you, appreciate that! I had made a db entry here https://appdb.winehq.org/objectManager.php?sClass=version&iId=42441 and linked the bug here https://bugs.winehq.org/show_bug.cgi?id=57662 previously. The db entry [links the bin](https://www.acclaimsoftware.com.au/download/). The application relies heavily on oleaut32 being correct, which it isn't even close to. The vast majority of my merge requests have been work around that. Unfortunately, all so far have been subject to either drive-by "reviews" and then subsequent ignores or responses similar to the above. The issue with the philosophy of the one stated by @julliard is that "resources" will remain small if you say "don't change other peoples code" (in another merge request last week) because that has a direct mapping to telling new developers to basically **** off. These "newcomers" can contribute and help alleviate resource constraint that frankly everyone who is a adult suffers from. Working with people improves that. On the technical side, fixing code that has the potential to crash in trivially obvious ways, violates documented behavior because it may not have an immediate effect on _your_ computer Alexandre isn't really a logical argument in the slightest. Such changes hardly amount to 'churn' that directly fix segmentation faults. Additionally I sent in a patch last week that fixes a regression made to oleaut32 that occured in the last couple of weeks, totally ignored. Typically fixing memory corruption issues and consolidating common paths into helpers written consistently usually helps people reach their "goals" faster. The only thing this "straight forward, no churn we have limited resources" messaging communicate to developers outside your close knit circle is a toxic attitude.
btw "extra runtime checks" on validating user controlled pointers to a API is a completely irreverent nano-optimisation, CPU's have branch-predictors. Fixing the oleaut32 implementation from O(n^3) strcmp() lookups to a hashmap, which is how it is meant to work, is far more relevant. If you are worried about branch-complexity, the other patches I sent in that reduce cyclomatic branch complexity help the `if (true) { if (true) { if (true` cascades because base-conditions are not quickly interrogated and returned from.