go-ole/go-ole

win32 ole implementation for golang

Go OLE

Go bindings for Windows COM using shared libraries instead of cgo.

By Yasuhiro Matsumoto.

Install

To experiment with go-ole, you can just compile and run the example program:

go get github.com/go-ole/go-ole
cd /path/to/go-ole/
go test

cd /path/to/go-ole/example/excel
go run excel.go

Continuous Integration

Continuous integration configuration has been added for both Travis-CI and AppVeyor. You will have to add these to your own account for your fork in order for it to run.

Travis-CI

Travis-CI was added to check builds on Linux to ensure that go get works when cross building. Currently, Travis-CI is not used to test cross-building, but this may be changed in the future. It is also not currently possible to test the library on Linux, since COM API is specific to Windows and it is not currently possible to run a COM server on Linux or even connect to a remote COM server.

AppVeyor

AppVeyor is used to build on Windows using the (in-development) test COM server. It is currently only used to test the build and ensure that the code works on Windows. It will be used to register a COM server and then run the test cases based on the test COM server.

The tests currently do run and do pass and this should be maintained with commits.

Versioning

Go OLE uses semantic versioning for version numbers, which is similar to the version contract of the Go language. Which means that the major version will always maintain backwards compatibility with minor versions. Minor versions will only add new additions and changes. Fixes will always be in patch.

This contract should allow you to upgrade to new minor and patch versions without breakage or modifications to your existing code. Leave a ticket, if there is breakage, so that it could be fixed.

LICENSE

Under the MIT License: http://mattn.mit-license.org/2013

go-ole's Issues

Test Case for Date Variant

Create go-ole.github.io guide site repo

Create if doesn't already exist, then add template.

I'm going with just basic HTML with minimal JavaScript. I was thinking about making it an Angular site or using the dynamic tools that GitHub provides.

Right now I'm thinking about just doing it all manual. It will eventually become painful and another solution will be required to maintain the site.

Should Must* methods in oleutil package panic?

The oleutil package has Must and non-Must versions of a number of methods, such as CallMethod vs. MustCallMethod, and so on.

I noticed that the Must methods simply ignore errors that occur. I assumed that these functions would panic instead, so that you could catch them with a deferred function. A deferred function could recover() from the panic, get the OleError, and return it to the caller, converting it to a more appropriate error type if needed.

This approach (panic in the Must functions on error) would also follow the existing pattern found with Compile and MustCompile in the standard regexp package in Go.

To me, using Must in the function name implies that the function call must succeed without any errors, and if an error does occur, the only other option is for it to panic (in my mind).

Is there a reason the oleutil Must functions don't panic?

Remote WMI query with user name and password

I am trying to run remote WMI query with user name and password , i could not find any guide on this,

Cannot go get on Mac

I'm getting the following:

$ go get -v github.com/StackExchange/wmi
github.com/StackExchange/wmi (download)
github.com/mattn/go-ole (download)
github.com/mattn/go-ole
# github.com/mattn/go-ole
../../Go/src/github.com/mattn/go-ole/com.go:80: undefined: syscall.StringToUTF16Ptr
../../Go/src/github.com/mattn/go-ole/com.go:91: undefined: syscall.StringToUTF16Ptr
../../Go/src/github.com/mattn/go-ole/com.go:112: undefined: syscall.StringToUTF16Ptr
../../Go/src/github.com/mattn/go-ole/com.go:178: undefined: syscall.StringToUTF16Ptr
../../Go/src/github.com/mattn/go-ole/variables.go:8: undefined: syscall.NewLazyDLL
../../Go/src/github.com/mattn/go-ole/variables.go:9: undefined: syscall.LoadDLL
../../Go/src/github.com/mattn/go-ole/variables.go:10: undefined: syscall.LoadDLL
../../Go/src/github.com/mattn/go-ole/variables.go:11: undefined: syscall.LoadDLL
../../Go/src/github.com/mattn/go-ole/variables.go:12: undefined: syscall.LoadDLL
../../Go/src/github.com/mattn/go-ole/variables.go:13: undefined: syscall.LoadDLL
../../Go/src/github.com/mattn/go-ole/com.go:178: too many errors

You might be wondering: why on earth would you want a Windows module on OSX? Because we're building a cross-platform app that we cross-compile.

Do you have any recommendations on how we can solve / work around this?

Memory corruption when calling into WMI

We're using this library to run WMI/WQL queries. Things work most of the time as expected. Sometimes we get \u0000 values in strings. Sometimes a panic occurs (usually a "panic: runtime error: invalid memory address or nil pointer dereference"). Our current belief is that there is some memory corruption going on somewhere, and this is causing these errors. We cannot figure out how to reliably reproduce them. It can take seconds or tens of minutes to occur.

Our project (https://github.com/stackexchange/wmi) has some tests. The TestString function will search for these \u0000 characters. If you take out the break, it'll induce a panic quickly.

Is there a chance this is a bug with your library somewhere? I'm more inclined to suspect it isn't, but rather that we're calling into COM incorrectly. Any help?

SysAllocStringLen fails with empty string

The following test panics:

func TestSysAllocStringLen(t *testing.T) {
    SysAllocStringLen("")
}

@mgspross - I'm not familiar with Windows to know what the correct fix is here otherwise I'd propose one.

[Question] Go COM Server

Doing some research, it seems like it could be possible to have a COM Server in Go. Obviously, it couldn't be in-process or a DLL, but it could possibly be an executable. I'm also adding more functions that work with supporting COM servers.

Is there something that would inheritly prevent Go from being an remote or local executable COM Server process? If it is possible, then what is necessary to implement it or help developers with the library implement it?

If it is possible, then it could allow for removing the need for a C# testing application. The testing COM server application would just be Go.

Is there tool to display available methods and properties?

Could anyone provide a helper function to display all properties and methods in an IDispatch type?

Structuring of codebase

I was thinking about restructuring and I was wanting some feedback before I start working on this with my fork. The question is whether this would be accepted if I went ahead with this idea. As well as what would be broken and have to be changed for those already using this library.

TL;DR: Move the code from the current base directory to child directories so someone can go get github.com/mattn/go-ole/core and go get github.com/mattn/go-ole/core-shared and go get github.com/mattn/go-ole/oleutil instead of having to download everything.

• ./core
• ./core-shared
• ./core-cgo
• ./oleutil
• ./examples
• ./documentation
• ./test
• ./test/project
• ./test/data

Core directory would contain all of the class structures that be type casted for COM. It would also include interfaces for core-shared and core-cgo to implement, so that you could use either one. Most of the code that could be used throughout the other packages would be contained in core.

Core-shared directory would contain most of the existing code with modifications to match interfaces in core.

Core-Cgo directory will mostly not exist until it is started by someone. It will be the cgo dependency for COM.

Oleutil directory will contain the current oleutil. I was also thinking of moving some of the helper code I created to here as well or simply removing the helper code I created, since it probably isn't being used.

Test/Project directory will include the Visual Studio Community 2013 project for the C# COM server for testing.

Documentation directory will contain the documentation files for describing how to use the library for Google Go. This should include the motivations behind the library structure and oleutil usage.

Test COM Application

There needs to be a test application / DLL that implements all implemented COM functionality in the server in order for the client library to call for testing.

At the very least the COM server needs to implement IUnknown and IDispatch. It also needs to implement SafeArrays in the various Variant types and other Variant types.

Finish inline documentation for all functions

Any functions or structure elements that can have inline documentation needs to have inline documentation.

Part of this is simply review. Most of the functions, structures, etc should already have inline documentation.

Add inline documentation to those functions, structures, etc that are missing inline documentation.

Add go-ole package section to Documentation Menu

The documentation menu will provide for all of the available projects, complete and stable like this one and the other experimental, incomplete ones in the rest of the group.

The Go-ole will need to be filled out with examples, along with a Quick Start guide. There will be two different references. One for how to use functions. Just a brief, "here are some examples and brief explanation." Along with cookbook and working application examples.

Some of the current examples that exist in the repo will be ported over to the examples. These need to be tested and ensure that they still work. Not sure where someone can get Excel. Might sign up for Office 360.

This will be a large section and will be broken into separate tickets.

Guide Documentation

There are currently three ways to use the library. The OLEUtil helpers and there is a wrapper library that attempts to define a more object-oriented way of accessing COM. Finally, the procedural wrapper of shared library.

There needs to be better documentation for using the library. A guide for getting into the library other than the examples which does help, but doesn't go far enough.

What I'm thinking of is expanding the README.md to include a basic guide, then create gh-pages for a web site that includes better guide documentation for using functions and objects.

How to get returned data from the MustCallMethod?

Hi,
The source below is returning a version information as a string. But how to get it from dbinfo?

dbinfo := oleutil.MustCallMethod(conversationSystem, "Request", "Version").ToIDispatch()

IConnectionPoint.Unadvise method calls the wrong vtable function

The IConnectionPoint.Unadvise method is calling the wrong function in the underlying object's vtable: its calling Advise instead of Unadvise on the underlying object.

See https://github.com/mattn/go-ole/blob/71907b1d6af87ef659ff66a9d57e283ee1d955d3/iconnectionpoint.go#L55

Add how to test go-ole to guide documentation

Move the Travis-CI and Appveyor from the readme to the guide documentation and fill it out with more information on the entire process for testing on Travis-CI and Appveyor.

This should probably go into the Contributing section, which will also need to be filled out with more copy.

Version Number and Backwards Compatibility

I want to introduce versions and use semantic versioning. The question is what to call the current working copy given that it is stable enough for use and what to call my fork, if it is accepted. If it is not accepted, then ignoring that and focusing on the working copy version going forward.

Question 1: What version do we call the current working copy?

1. Version 0.1.0
2. Version 1.0.0

Question 2: Do we maintain previous versions?

What this means is that if the next version is 1.1.x, then 1.0.x support is dropped once 1.1.0 is released. Once 2.0.0 is released, then 1.x.x support is dropped. I would suggest always accepting pull requests, but testing is usually the problem and reason why previous versions are not supported.

Cannot read string arrays

I get a panic: runtime error: invalid memory address or nil pointer dereference any time I try to check the contents of a string array.
The problems happens after I call ToStringArray, inside UTF16PtrToString. Depending on whether I put some print statements inside the UTF function I sometimes get a bad pointer panic. The print statements contain strings only.
An example for getting this error:
http://stackoverflow.com/questions/20365286/query-wmi-from-go/20366574#20366574
Just replace Win32_WinProcess with Win32_NetworkAdapterConfiguration and try to get the IPAddresses for example:

arr, _ := oleutil.GetProperty(item, "IPAddress")
fmt.Println("Got IDispatch")
arr2 := arr.ToArray()
defer arr2.Release()
fmt.Println("Trying to get string array")
arr3 := arr2.ToStringArray()
fmt.Println(arr3)

Tried it on both Win server 2012 and Win 8 both amd64. Both running go 1.2.1.

May be related: https://code.google.com/p/go/issues/detail?id=8228. Even though I tried reverting that commit and it still does not work.

license?

Hi,
What is the license for the project's code? I can't seem to find any mention in the repository...
Thanks

Excel example leave process running

The Excel.exe doesn't terminate

Use VariantClear to clear VARIANT parameters passed to ole.IDispatch.Invoke

After reading this MSDN page, I think VariantClear should be used to free memory used by the VARIANT parameters that are created in the IDispatch.Invoke in the library.

Currently, the go-ole wrapper for IDispatch.Invoke calls SysFreeString on string parameters; however, VariantClear seems like a more appropriate choice, since it can correctly free any VARIANT based on its type (i.e. it will call SysFreeString on strings and properly release SAFEARRAY's, etc.). If I am reading the documentation correctly, it sounds like it is safe to call this function on any VARIANT type.

Could you provide Excel open file example?

Just try to use Excel in the example.
I found it only contains a very simple idea - 'write a int value to empty excel'.

I wish the example could extended to

1. 'Write int,string,formula,date to a Excel file'
2. Save the file
3. Read the file
4. Show the variables in different type

The most difficult part are two:

1. How to convert variable between Excel and Go?
2. How to know the Excel ole provide functions?

Get 32-bit Build Working on Appveyor

Increase Go Minimum Version Requirement

Survey to increase Go version to 1.4 to allow for go generate and internal packages.

Some of the tools may actually require 1.5, but I think the types package should be fine whether they are used in 1.4 or 1.5.

@mattn

Does anyone use the Connect API?

If anyone is watching this repo and uses the connect API, please let me know.

I'm kind of need to decide whether to remove the connect API or deprecate it. Really, it is already deprecated. The issue is that I don't want to have to jump the version to 2, just to remove the connect API.

The other part is whether to document the API in the guide documentation. I'd rather spend more time documenting how to use the oleutil, than the connect API.

The other option is to use oleutil in the connect API and move some parts out into oleutil, if not already.

Cell's value is wrong, if set to float32/float64.winxp 32bit+excel 2003

in example excel, if set to float32/float64:
oleutil.PutProperty(cell, "Value", 12345.6789)
Cell's value is set to 0.

Add test cases for scalar variants.

Need test cases for

• numeric values
• string values
• float values

Definition of GetActiveObject appears to be incorrect

https://msdn.microsoft.com/en-us/library/windows/desktop/ms221467(v=vs.85).aspx

Issues converting COM strings to Go strings (UTF16PtrToString function)

I found a few limitations with the way UTF16PtrToString is currently implemented:

• It uses a hard-coded 10,000 character buffer, which means it can't support COM API's that can return larger strings.
• It cannot support BSTR's fully, since it terminates on the first NUL character found; however, it is valid for a BSTR to contain NUL (or any other byte value).

To resolve these issues, I recommend the following changes:

• Remove the 10,000 character limit by allocating a []byte slice dynamically, and using unsafe.Pointer to loop through the original string.
• Determining the size of the slice depends on the actual type of the string pointer: for a BSTR, SysStringLen can be used to get the length; for an LPOLESTR, length would be determined by searching for the first NUL character.
• Because of the differences between BSTR and LPOLESTR (go-ole uses functions that each of these types), two separate functions are needed: one for BSTR's, and one for LPOLESTR's, and the existing calls to UTF16PtrToString in the rest of the library need to be changed to call the appropriate new conversion function.

build fails

Hi,
"go get github.com/mattn/go-ole" fails on the installation step.
Thereafter, building the examples fail with the same errors:

# github.com/mattn/go-ole
../../com.go:72: undefined: syscall.StringToUTF16Ptr
../../com.go:83: undefined: syscall.StringToUTF16Ptr
../../com.go:104: undefined: syscall.StringToUTF16Ptr
../../com.go:162: undefined: syscall.StringToUTF16Ptr
../../iconnectionpoint.go:45: too many arguments in call to syscall.Syscall
../../variables.go:8: undefined: syscall.LoadDLL
../../variables.go:9: undefined: syscall.LoadDLL
../../variables.go:10: undefined: syscall.LoadDLL
../../variables.go:11: undefined: syscall.LoadDLL
../../variables.go:12: undefined: syscall.LoadDLL
../../iconnectionpoint.go:45: too many errors

exit status 2

Good Luck!

Use SysAllocStringLen instead of SysAllocString to allocate BSTR's

The library currently uses SysAllocString to allocate BSTR's when strings are passed to COM functions. I'd recommend using SysAllocStringLen instead, due to limitations with SysAllocString.

The problem with the current implementation is that a BSTR is actually allowed to contain binary data, including NUL characters. SysAllocString doesn't support this contract (it terminates the string when it finds a NUL character), but SysAllocStringLen does.

In other words, SysAllocStringLen lets you pass a pointer to a string, plus the length of the string, which allows you allocate strings that contain arbitrary bytes. I think this also makes sense in the context of Go as well, since strings in Go can also hold arbitrary bytes.

This change also won't change functionality when passing "normal" strings around, so it should be low-risk.

SafeArray Support

There doesn't currently seem to be any code for traversing a COM SafeArray. These appear to need to be done by an API and then freed. API call tells Windows that it is safe to free the memory for the SafeArray.

Write integration tests to fully test library

I think it is time to break out the C++ or C# Visual Studio coding (probably go with C#) to develop a integration test suite. The current issues could be resolved with more test cases that test a number of the issues being brought up.

The proposal is to develop a COM server that implements a number of basic and advanced functions that will utilize each of the functions within the Go library. As well as address some of the issues that were brought up to ensure that similar issues are not introduced in the future.

Other tests should involve common COM server that all Windows machines should have installed to further allow testing against whatever can be called to further insure stability.

This may also involve finishing the library just for completion sake and to ensure that the library is production ready. Given that more people appear to be using the library.

TODO: check following code.

var IID_IHTMLElement = &ole.GUID{0x3050f1ff, 0x98b5, 0x11cf, [8]byte{0xbb, 0x82, 0x00, 0xaa, 0x00, 0xbd, 0xce, 0x0b}}

    ole.CoInitialize(0)
    unkonwn, _ := oleutil.CreateObject("InternetExplorer.Application")
    ie, _ := unkonwn.QueryInterface(ole.IID_IDispatch)
    oleutil.CallMethod(ie, "Navigate", "google.com")
    oleutil.PutProperty(ie, "Visible", true)
    for {
        if oleutil.MustGetProperty(ie, "Busy").Val == 0 {
            break
        }
    }       
   document := oleutil.MustGetProperty(ie, "document").ToIDispatch()
        anchors := oleutil.MustGetProperty(document, "anchors").ToIDispatch()
        /*window := oleutil.MustGetProperty(document, "parentWindow").ToIDispatch()*/
        /*oleutil.MustCallMethod(window, "eval", "alert(document.anchors.length);")*/
        n := int(oleutil.MustGetProperty(anchors, "length").Val)
        fmt.Println("n=", n)
        for i := 0; i < n; i++ {
            item := oleutil.MustGetProperty(anchors, "item", i).ToIDispatch()
            fmt.Println("item: ", item)
            elment, err := item.QueryInterface(IID_IHTMLElement)
            fmt.Println(elment, err)
        }

Should VT_UI4 be VT_I4? line 145 in idispatch.go

line 145 in idispatch.go:
case int, int32:
vargs[n] = VARIANT{VT_UI4, 0, 0, 0, int64(v.(int)), 0}

Fix type-assertion for uint16 parameters passed to ole.IDispatch.Invoke

The type assertion for case uint16 in ole.IDispatch.Invoke is type-asserting the value to int16 but should be type-asserting to uint16, as case *uint16 does.

Reference: https://github.com/mattn/go-ole/blob/ea5b3694a173a167ac792f7951adc39b1583c7d4/idispatch.go#L140

Most of the examples do not work.

Most of the examples do not work.

.../sample/excel/excel.go

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x4210e3]

goroutine 1 [running]:
ole.getIDsOfName(0x0, 0x3b1db8, 0x1, 0x1, 0xc0800000c8, ...)
    C:/Work/test/src/ole/idispatch.go:74 +0x163
ole.(*IDispatch).GetIDsOfName(0x0, 0x3b1db8, 0x1, 0x1, 0x0, ...)
    C:/Work/test/src/ole/idispatch.go:41 +0x81
ole/oleutil.PutProperty(0x0, 0x4bfdc0, 0x5, 0x3b1e48, 0x1, ...)
    C:/Work/test/src/ole/oleutil/oleutil.go:76 +0xb2
main.main()
    C:/Work/test/src/ole/example/excel/excel.go:18 +0x3b4
Error: process exited with code 2.

Separate out code into other files

Separate code into chunks to help with organization and comprehension.

Add IStream Implementation

Honestly, I think it might be better to just add the rest of the COM interfaces and implement it, since enough requests are starting to come in for other interfaces.

This issue is for COM IStream. Other interfaces should be made in new issues.

Memory corruption with go 1.3

Issue 8228, comment #1 on the Go issues list has a demonstration of a bug using only this package and only on go 1.3 for amd64. Create as go-ole/oleutil/oleutil_test.go:

package oleutil

import (
    "runtime"
    "testing"

    "github.com/mattn/go-ole"
)

func TestFreelistCorruption(t *testing.T) {
    runtime.LockOSThread()
    defer runtime.UnlockOSThread()

    ole.CoInitializeEx(0, 0)
    defer ole.CoUninitialize()

    unknown, err := CreateObject("WbemScripting.SWbemLocator")
    if err != nil {
        t.Fatal(err)
    }
    defer unknown.Release()

    wmi, err := unknown.QueryInterface(ole.IID_IDispatch)
    if err != nil {
        t.Fatal(err)
    }
    defer wmi.Release()

    _, err = CallMethod(wmi, "ConnectServer")
    if err != nil {
        t.Fatal(err)
    }
}

My guess is this is the same bug as in #13. However, unlike that issue, this one still triggers when the GC is enabled. It does not trigger on the 32-bit version.

Test Cases for Enum Variant

Readme accidently merged experimental status text

It seems commit 92a2c84 accidently included the following text in the readme:

This repository was created for experimentation and should be considered unstable.

It is being used to develop a few working projects and fixes will be applied and when it is stable enough it will be merged into the mattn repository. For now, simply use mattn repository, unless you want to live on the edge. No warranties.

This does not make sense as it is the mattn repository

connect to microsoft outlook

Hi, is there a way to connect to microsoft outlook for sending an email?

Thanks,
Gerald

Add support for defining COM interface wrappers in Go via structs and struct tags

I am playing around with the idea of adding support for defining COM interfaces in Go using struct's to define the interface, where each field is actually the definition of a property or method, using func types to specify the method signature, and struct tags to specify whether the field represents a method or a property on the COM object.

This is easier to show than to explain, so here is an example of how MSXML2.DomDocument's interface would be (partially) implemented using this technique:

// COM "interface" definition for MSXML2.DomDocument.
//
// Each method/property is declared with a field with the same name as the method or property,
// and the field's type is set to a function type that matches the method/property's call signature (using Go types)
//
// The `ole` tag is used to specify whether a given field represents a method or a property for objects of this type
//
type DomDocument struct {
    Load    func(file string) bool `ole:"method"`
    LoadXml func(xml string) bool  `ole:"method"`
    Xml     func() string          `ole:"property"`
    Save    func(file string)      `ole:"method"`
}

You would use it as follows:

doc := DomDocument{}
oleutil.CreateOleWrapper("MSXML.DomDocument.6.0", &doc)

if(doc.LoadXml("<root><child/></root>")) {
    fmt.Println(doc.Xml())
}

This works by using reflection to find fields in the struct that have a function type, and dynamically creating wrapper functions that call oleutil.MustCallMethod or oleutil.MustGetProperty as needed.

For now, this is just a little experiment, and we'd have to flesh out a number of things (like returning errors from methods, properly releasing objects that are created, etc.).

I wrote a complete, working proof-of-concept here:

https://gist.github.com/mgspross/dfadc21f16db2a56ed27

What do you guys think of the general concept here?

implement VT_DATE

Maybe we could use this to implement.

https://godoc.org/github.com/tealeg/xlsx#TimeFromExcelTime

I've tried to edit variant.go, but failed.

//case VT_DATE:
//  return v.ToIDispatch() // TODO: use VariantTimeToSystemTime
case VT_DATE:
    return xlsx.TimeFromExcelTime(float64(v.Val), false)

Size of VARIANT type is wrong when GOARCH == "386"

Currently I'm using go-ole to interoperate with legacy VB6 code. However, VB6 can only generate 32-bit binaries/libraries, which in turn means that COM classes written in VB6 only work when called from 32-bit programs (i.e. programs compiled with GOARCH == "386").

In go-ole, the ole.VARIANT type compiles to the wrong size for 32-bit platforms - it should be 16 bytes, but ends up being 24 bytes (24 bytes is the correct size for 64-bit platforms).

This means it sometimes works in 32-bit programs, and sometimes doesn't: for example, it won't work if you use ole.IDispatch.Invoke to call a method that takes more than 1 parameter, because the VARIANT array that the function creates to pass the parameters to the method will have the wrong element size, so the called COM object won't be able to properly separate out the parameters, and will usually crash as a result.

To fix this, the VARIANT type needs to be changed to support both 386 and amd64.

Go Generate from Type Information

Edit: This has been updated to match the information below in #59 (comment).

The tool will require either Windows or WINE and the COM server must be registered.

This has been on my wish list for a long time and with Go Generate tool, I think it could finally be achieved within a reasonable amount of time.

The idea is to generate the Go code based on the COM type information. This must include helper functions that call into the Go OLE library functions (helpers or core) for the programmer. This could also include other Go language features to help with the process of passing data around.

So the tool would generate all or most of the code required to interop with COM or OLE with the command:

go generate

with the comment:

//go:generate [ole|com|???] -o something.go -i [com-uuid|registered name]

The -t defines how the interface or class methods and properties are invoked.

• -t direct - Casts the COM pointer to Go structure with methods calling out to pointers.

  This is useful for outputting internal COM interfaces or other raw interfaces. This follows the format and standard of the current interface packages.

  The goal is to be able to output the current hand coded COM interfaces using the Go generate tool. This should provide improvements that are made to the go generate tool, to the internal packages. As well as support more interfaces without having to hand code each one.

• -t idispatch - Uses the IDispatch COM interface to invoke properties and methods using helpers.

  This will create a Go structure with type methods that will invoke based on the arguments. oleutil might be rolled back into the main library and functions used in the generation of the object and its methods.

Paradigm

The output should always be a structure type with type methods that invoke based on parameters. How the developer uses the structure will be up to the developer. Technically, the current paradigms are both procedural and object-oriented. The functions are what actually implement the calls into the COM interface or object.

The type methods use the functions and pass the necessary data and parameters. The purpose is to allow for other structures and their type methods to use the existing functions without having to duplicate any code other than the type method structure.

For example, every COM interface inherits from IUnknown interface and so each structure has type methods that duplicate the definition found in the iunknown package. Technically, every interface already has these type methods. The reason they are explicitly defined is for documentation and for testing whether the design is the best way to output the code. Testing might remove the explicit type methods from additional structures.

This needs to also output the COM client initialization, which is then used throughout the generated code.

Additional Go Tool Features

The COM or OLE Go tool should also be able to output current COM interfaces and objects along with type information in either human readable or JSON format. Should also have a search feature to quickly filter results. This will hopefully allow for developers to quickly find whether the COM object is registered and retrieve additional information before generating code.

Add support for passing byte slices to IDispatch.Invoke

I am working with a COM API that contains methods that accept and return byte arrays (SAFEARRAY(unsigned char) in the IDL). However, go-ole doesn't currently support this. I also saw that the SAFEARRAY support in go-ole appears to be a "work-in-progress," so I also think that support for arrays in general would be beneficial, but - for now - byte arrays would be a good start (for my use case at least).

Add support for the IEnumVARIANT dispatch interface

We currently have support for IDispatch, is it difficult to add support for IEnumVARIANT? See https://msdn.microsoft.com/en-us/library/windows/desktop/ms221053%28v=vs.85%29.aspx.