summaryrefslogtreecommitdiff
path: root/source4/lib/dcom/common/main.c
AgeCommit message (Collapse)AuthorFilesLines
2007-10-10r4624: Several crash fixes for DCOMJelmer Vernooij1-1/+7
More work on the example class implementation (This used to be commit 1f8f4dd179d5aa0472c676d115dc2fc1749ce32d)
2007-10-10r4618: - tidied up the alter_context client code a bitAndrew Tridgell1-16/+32
- there is no alter_nak or alter_ack packet, its all done in an alter_response - auto-allocated the contex_ids - tried to fix up the dcom code to work again with alter_context. Jelmer, please take a look :) (This used to be commit dd1c54add8884376601f2f8a56c01bfb8add030c)
2007-10-10r4616: the first phase in the addition of proper support forAndrew Tridgell1-1/+3
dcerpc_alter_context and multiple context_ids in the dcerpc client library. This stage does the following: - split "struct dcerpc_pipe" into two parts, the main part being "struct dcerpc_connection", which contains all the parts not dependent on the context, and "struct dcerpc_pipe" which has the context dependent part. This is similar to the layering in libcli_*() for SMB - disable the current dcerpc_alter code. I've used a #warning until i get the 2nd phase finished. I don't know how portable #warning is, but it won't be long before I add full alter context support anyway, so it won't last long - cleanup the allocation of dcerpc_pipe structures. The previous code was quite awkward. (This used to be commit 4004c69937be7e5dae56f9567ca607f982d395d3)
2007-10-10r4037: fixed a bunch of "might be uninitialised" warnings after enabling -O1 ↵Andrew Tridgell1-1/+1
in my compile (This used to be commit 0928b1f5b68c858922c3ea6c27ed03b5091c6221)
2007-10-10r3972: use GUID_* naming context and move GUID_* functions to one placeStefan Metzmacher1-4/+4
metze (This used to be commit 523e6acf4fec5d4946fa7c0c89f40d7d712c9f3a)
2007-10-10r3898: Work towards local/server DCOM support, start workingJelmer Vernooij1-8/+118
on Simple example server side implementation (This used to be commit 98afb504d95ccca4d6ec48273e10b52ccfa26ad0)
2007-10-10r3689: Large number of COM updates:Jelmer Vernooij1-82/+161
- Work on server side and local COM support (should work, just no example classes yet) - Use vtables so that local and remote calls can be used transparently - Generate 'proxies and stubs' rather then heavily modified code in client.pm and server.pm. proxies (client side code) are generated in proxy.pm, stubs (server side dispatchers) are generated in stubs.pm - Support registering classes and interfaces - DCOM interfaces no longer have to be in the same IDL file as their base interface, which will allow us to split up dcom.idl (This used to be commit 7466947a23985f9bb15209b67880f7b94dc515c8)
2007-10-10r3667: Small COM fixesJelmer Vernooij1-14/+16
(This used to be commit 7484b9be7423ccd7e37432951700939e8a53d513)
2007-10-10r3626: More minor DCOM fixesJelmer Vernooij1-5/+12
(This used to be commit 709f279b192c8f9eeea04749169c00f2d57b20d3)
2007-10-10r3625: Couple of minor DCOM bugfixesJelmer Vernooij1-59/+20
(This used to be commit 6f5bf44ade8bad10c6cf08a7d6e3528ec6b4ec8a)
2007-10-10r3611: DCOM client support works!!Jelmer Vernooij1-2/+2
The torture test DCOM-SIMPLE now successfully does an IStream_Read and a IStream_Write call. This test can now be run successfully against the "Simple DCOM" Visual Studio example. (You have to quote out line 337 in pidl. pidl complains if the variable that contains the array size follows the array. I still need to fix this properly) Next goals: - Clean up code - Server side support - Support custom marshalling - Support DCOM interfaces in files other then dcom.idl (This used to be commit 8693344772a9b700533179f4bacfe27ec27dfcfe)
2007-10-10r3606: More DCOM fixes:Jelmer Vernooij1-23/+90
- OXID tables work now. IOXIDResolver is used if there is used for getting a STRINGBINDING if none is known yet - Add custom dissectors for STRINGARRAY and DUALSTRINGARRAY. If there's a way to get rid of these later on (by supporting them thru pidl somehow), I'd be happy to use that instead of doing it manually. I can now get to the point where we have created an object and are connected to it. The only thing left to do is being able to set the Object UUID properly.. (This used to be commit 54e1e5edca50d3cd496c080715e84ec62cb2a10c)
2007-10-10r3601: Lots of smaller DCOM updates and fixes. Adds oxid tables, properJelmer Vernooij1-31/+176
use of contexts. (This used to be commit 93eb3cd99c4fb065a69eabcead0c33804259c976)
2007-10-10r3527: I hate compiler warnings...Stefan Metzmacher1-0/+2
metze (This used to be commit d264aacfd5b96c1fdb57fd1b6206835a7526eb3c)
2007-10-10r3515: Fix RemoteActivation correctly this time (-:Jelmer Vernooij1-4/+15
Thanks to tridge for some help on this one! (This used to be commit 1104667190aa144e2c7d79ece9a55502b98d0351)
2007-10-10r3514: Allow specification of username, password and domain and try to set ↵Jelmer Vernooij1-27/+93
up connection. (This used to be commit 8076db7a1f9e11c725e481a0bda4dbc354c9612f)
2007-10-10r3513: Add (the infrastructure for) DCOM support. Contents:Jelmer Vernooij1-25/+32
- Support for sending over the object UUID in DCERPC calls - Simple torture test for the DCOM "Simple" object - Generate extra argument for "object" interfaces in pidl - Some stubs for common DCOM functions (This used to be commit c052f2e1edd816206d8974af3140cec7ef97a70c)
2007-10-10r3488: Start using RemoteActivationJelmer Vernooij1-0/+92
(This used to be commit b4e81ffc648d30c4c501b168d5e2e562941648ac)