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 paps.
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.