On Mon Mar 3 12:36:12 2025 +0000, Jinoh Kang wrote:
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. I understand. As someone who had to fix COM-related race bugs, I largely agree that the current state of COM/OLE-related libraries isn't exactly ideal. Wine's primary goal, first and foremost, is to maximize compatibility with Windows apps, even if it doesn't perfectly emulate Windows. If a simple stub is enough to unblock execution, we do that. If a partial implementation gets it forward without breaking other apps, it's good enough. Given enough time we could "get everything right" the first time, but trust me, with hundreds and thousands of Windows DLLs (Wine already has ~700 of them!) we really need some prioritization to match an operating system developed by a multi-national corporation. Wine itself is about incremental changes, rather than a clearly defined roadmap. It's expected that cruft accumulates over time. Sometimes, maintainers can find time to clean them up by themselves. Other times, it's expected of contributors to take up the work. After all, once it's accepted and merged, it's the maintainers' job now to keep it working and avoid breaking other apps. See https://docs.google.com/presentation/d/11rMc8PBeyMItV6hv31OHSZ626_6FCZxjX6Zx... (from Linux kernel community) for more on this.
Validating does not "hide bugs", you are just making stuff up now. The
application expects to have `E_POINTER` upon a `NULL` passed in. The reason why a `NULL` was passed is irrelevant, only that a specific state is expected. You have no idea what the application is doing nor why, only that it is a matter of fact that this is the behavior expected from the API. Since we cannot control the application code we can only provide it with what it expects and fix bugs pertaining to that. Incidentally your reasoning about Microsoft application being buggy is nonsensical, it has nothing to do with API's validating arguments - a blindly obvious practice in software engineering - it has to do with their huge API surface inherits vast amounts of complexity and from which issue emerges. Make no mistake, we are aware of apps that rely on error handling behavior and NULL pointer checks (just look for `E_POINTER` in wine codebase). In absence of an explicit evidence of an app relying on this particular behavior, we assume that the source of the "invalid pointer" bug lies elsewhere. Not fixing the root cause has *historically* been a common source of error from new contributors, so you'll probably encounter this default objection unless you're explicit about the error-check reliant behavior from the application side.
@iamahuman thanks mate. I can see what your underlying reasoning is about people doing drive-by patches that fix a seg fault that is downstream for something else and you rather the application crash. However it is sort of a user facing behavior of crashing to track a bug report of the upstream issue that does not really generalise since other applications that expect `E_POINTER` benefit. This is obvious defined behavior.
I sense the underlying issue below this is that you have got these drive-by one liner patches before without a deeper understanding on how to investigate and contribute to wine more long term, hence you linked me to how kern dev is done. I assure you this isn't my first rodeo. Working on radeon graphics, the driver is half the size of the kernel, mesa3d is very complex and working on coreboot things are sometimes very hard to debug when you don't yet have a DRAM controller. Yes, wine has a big job but that is how software is today but we just get on with it.
This patch was ultimately broken off from the rest of my larger bodies of work due to the review behaviors in order to puck out something least controversial to build momentum. It seems pretty clear to me now that upstream is a wast of my time.
Comments like,
I've seen a dozen oleaut32 patches that are mostly moving code around and renaming variables, it's impossible to tell if there was a valid bug fix buried in there.
shows a lack of reciprocating investment to improve things. idk if some specific wine devs got burnt in the past from lots of drive-by patches that don't fix things so now have overcompensated and ignore new developers.
The reality is that the oleaut32 implementation as-is in-tree is in a unworkable state to morph it into something actually functional.