[_comobject.py] Use WinDLL/OleDLL instead of windll/oledll

[moi15moi]

See #735

[junkmd]

This change requires a bit more consideration.

For example, names like kernel32 do not involve both ole and win being used together within this module, so I think there’s no need for a redundant suffix like ..._from_windll. Simply naming it _kernel32 should suffice.

This package already has existing aliases for windll.ole32 and oledll.ole32. Following this naming convention would likely align better with the established practices of this package.

comtypes/comtypes/__init__.py

Lines 123 to 125 in 4abba29

	# Initialization and shutdown
	_ole32 = oledll.ole32
	_ole32_nohresult = windll.ole32 # use this for functions that don't return a HRESULT

Additionally, the _comobject module has so far avoided importing symbols from automation at the top level.
7f9a73d

comtypes/comtypes/_comobject.py

Lines 46 to 50 in 4abba29

	# so we don't have to import comtypes.automation
	DISPATCH_METHOD = 1
	DISPATCH_PROPERTYGET = 2
	DISPATCH_PROPERTYPUT = 4
	DISPATCH_PROPERTYPUTREF = 8

As for importing symbols for assignment to argtypes, I’m uncertain about the potential impact in areas that might not be covered by the tests.

I believe the concept of this change is sufficiently useful.
However, at the initial stage, we’d prefer to start with simpler replacements that have minimal impact, and require less consideration.

For example, changes to a module like server/localserver.py, where only oledll is replaced and symbols are imported exclusively from standard libraries, would be much easier to approve.

This PR can remain open, but if you submit another PR with changes to a module involving fewer replacements, that PR is likely to be merged first.

[moi15moi]

Additionally, the _comobject module has so far avoided importing symbols from automation at the top level. 7f9a73d

Those variables aren't even used. You want me to duplicate the code instead of simply importing it?

This PR can remain open, but if you submit another PR with changes to a module involving fewer replacements, that PR is likely to be merged first.

I will keep it open and won't opening any other PR.

[junkmd]

Additionally, the _comobject module has so far avoided importing symbols from automation at the top level. 7f9a73d

Those variables aren't even used. You want me to duplicate the code instead of simply importing it?

These symbols were used before _comobject and _vtbl were separated (#713, #715, #716).
While there are places where these symbols and integer literals should be replaced, it is true that they are currently unused.
Let's clean this up in a separate scope someday.

I was hesitant about whether to use a simple import or not, but I am clearly against duplicating code. Defining DISPID as an alias for c_long is not an issue, but duplicating VARIANT would undoubtedly become a technical debt.

Since I tested this change in my local env and pywinauto's CI pipeline and found no problems, I’ll go ahead and accept the import of automation for now.

Importing IDispatch or VARIANT without causing circular imports or undefined references suggests that this change is likely safe.
There may still be edge cases we haven’t encountered yet, but if that happens, we can address it by moving the definitions from the global level to within functions, for example.

[junkmd]

Thanks.