Re: directx

[jeffdbREMOVETHIS at netzone dot com (Mikey)]

On Sat, 02 Aug 1997 14:14:37 -0700, you wrote:

>Mikey wrote:
>
>> On Fri, 01 Aug 1997 21:34:43 -0700, you wrote:
>>
>> >I am glad that the headers in SDK_4_ming_cygwin32
>> >will compile using g++.  I just downloaded the files to patch my
>> mssdk
>> >platform headers.
>> >
>> >However the name mangling conventions of VC++ are irrelavent.  If you
>>
>> >write code that uses C++ and OLE it doesn't matter what compiler you
>>
>> It matters a lot, if you're trying to use pre written vc++ code,
>> because the declarations
>> of the INTERFACE() functions will be in c++, so you have to rewrite
>> them
>> to C. and I hate typing ;^).
>
>You have a point there.  However, I built the shellext sample in the
>platform sdk, it was a while ago, so don't ask me how I did it.  I had
>to change all sorts of header declarations.  Anyway it was written in
>C++, and it did link correctly.  However it also crashed when loaded by
>Explorer.  I think one of its problems was the fact that the compiler
>complained about member functions declared with stdcall, it said
>attribute ignored.  If it defaulted to C calling convention the stack
>would get corrupted pretty quickly.  In any event C works better for
>now.  My current project uses OLE for drag and drop.  It uses the C
>interface successfully to create my own objects(IDropTarget) and
>manipulate others such as IDataObject.
>
>> >because you only work with interface pointers.  All functions that
>> your
>> >program calls in other DLLs are declared and exported in C with no
>> name
>> >mangling(this doesn't count interface functions but you call them
>>
>> My point was that if you try to use the headers using g++ declaring
>> your classes and expecting to be able to link with the standard
>> libraries, you won't be able to.
>>
>
>I don't see why this is so.  If you are linking with a VC++ dll that
>exports classes, then you will have problems, but I know of no such
>instance where this happens.  Maybe I will try it out.  If you have any
>error messages that support this send it to me.
>
>
>> >through pointers).  One calls the C functions to get interface
>> pointers
>> >to objects.  You can work with C++ or C with these functions.  It's
>> >easier in C++ because you type less.  In C you must pass a pointer to
>>
>> >the object as the first parameter of any interface function.  In C++
>> >this is the equivalent of the this pointer which is handled
>> implicitly.
>> >For example:
>> >
>> >pUnknown->AddRef(pUnknown);  //C
>> >pUnknown->AddRef();  //C++
>> >
>> >And it gets worse if you declare your own objects in C as opposed to
>> >C++.
>> >
>> >I have built a shell extension with modifications of the SDK headers
>> and
>>
>> Was it dropext.dll?
>> Unfortunately although I was able to build dropext.dll, from the
>> win32api.exe
>> samples, it did the same to me, crashed the system after I added the
>> .reg file,
>> so I backed out my changes to the shellapi.h shlobj.h and shlguid.h
>> files, untill
>> I could get a better handle on what was going on.
>>
>
>Yes it was dropext.dll.  I had to link(ld) with the msvc++ library
>uuid.lib for the IID constants,  I don't know how or why this works.

I JUST FIGURED IT ALL OUT!!!

This works because uuid.lib contains the actual .obj files
what you ended up with was a statically linked binary, run
ar -t uuid.lib and you will see what I mean.

I am glad that you pointed this out to me, you have saved me
a lot of time and frustration THANKS ;^)))))))

The reason the shellext example crashed was probably because
the obj files in shell32.lib that contain the CLSID IID UID etc.
structures weren't there in libshell32.a, here are the changes I had to make to 
crtdll/Makefile to get the correct libraries for shell32 and uuid.

liboldnames.a: oldnames.def
        dlltool --dllname crtdll.dll --def $< --output-lib $@ -k

%.def: $(SDK)/lib/%.lib
        set -xv;\
        [ -d obj/i386/ ] || mkdir -p obj/i386/;\
        cp $< . ;\
        Objs=`ar -t $(notdir $<)|grep -v \\.dll`;\
        [ -z "$$Objs" ] && exit 0;\
        ar -x $(notdir $<) $$Objs;\
        ar -d $(notdir $<) $$Objs;\
        for file in $$Objs;do \
          objcopy $$file `basename $$file .obj`.o;\
          rm $$file;\
        done
        ../bin/lib2def $(notdir $<) > $@
        rm $(notdir $<)

lib%.a: %.def
        dlltool --dllname $*.dll  --def $<  --output-lib $@ -k
        set -xv;\
        Objs=`echo *.o`;\
        [ "$$Objs" = "*.o" ] && exit 0;\
        ar urvs $@ $$Objs;\
        rm *.o

# to keep a copy of the .def files uncomment the next 6 lines
#%.def: $(SDK)/lib/%.lib
#       -mkdir -p defs
#       ../bin/lib2def $< > defs/$@

also you might want to add 

echo fakefunc$RANDOM

to lib2def.sh right after echo LIBRARY etc. so the empty uuid.def file dosen't give you a syntax error.

I just built dropext.dll installed it and it works perfect!!!

>Since I wasn't using the lib to import function calls I thought it would
>be ok.
>
>> I'm pretty sure now that a major part of the problem was that I didn't
>>
>> take the time to "fix" the IID CLSID etc... pointers, to the
>> __imp_IID*
>> references in the import libraries, which is what I'm working on right
>> now.
>>
>> So I'm afraid the SDK patches aren't going to help you very much.
>>
>
>I found that some IID constants are in uuid.lib, however I am sure they
>can befound elsewhere as well.
>
>> >a shell extension example.  Although it crashed my system I know that
>>
>> >there were no link errors.
>> >
>> >Hopefully the headers in SDK_4_ming_cygwin32 will allow me to
>> compile,
>> >link and debug a working shell extension without crashing my Win95
>> >machine.  Thus far I have been unable to so.
>> >
>
>Eric Britten
>
>

(jeffdbREMOVETHIS@netzone.com)
delete REMOVETHIS from the above to reply
         Mikey
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".