IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
less likely that anyone will use pstring for new code
- got rid of winbind_client.h from includes.h. This one triggered a
huge change, as winbind_client.h was including system/filesys.h and
defining the old uint32 and uint16 types, as well as its own
pstring and fstring.
files don't need to match the type names in the generated headers
- with this type mapping we no longer need definitions for the
deprecated "int32", "uint8" etc form of types. We can now force
everyone to use the standard types int32_t, uint8_t etc.
- fixed all the code that used the deprecated types
- converted the IDL types "int64" and "uint64" to "dlong" and
"udlong". These are the 4 byte aligned 64 bit integers that
Microsoft internally define as two 32 bit integers in a
structure. After discussions with Ronnie Sahlberg we decided that
calling these "int64" was confusing, as it implied a true 8 byte
aligned type
- fixed all the cases where we incorrectly used things like
"NTTIME_hyper" in our C code. The generated API now uses a NTTIME for
those. The fact that it is hyper-aligned on the wire is not relevant
to the API, and should remain just a IDL property
- 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 :)
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.
- 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
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
- 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..
- 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
