G-Force vis-plugin porting to XBMC, need help plz

[questor/fused]

okay, with the great help from pike i've got a compiled version of my g-force-port compiled with the vs.net2003. but when i try to load it in xbmc i get unresolved symbols!

unable to resolve kernel32.dll setendoffile
unable to resolve kernel32.dll virtualprotect
unable to resolve kernel32.dll lcmapstringw
unable to resolve kernel32.dll lcmapstringa
unable to resolve kernel32.dll writefile
unable to resolve kernel32.dll rtlunwind
unable to resolve kernel32.dll getcommandlinea
unable to resolve kernel32.dll deletefilea
unable to resolve kernel32.dll setlasterror
unable to resolve kernel32.dll heapdestroy
unable to resolve kernel32.dll heapcreate
unable to resolve kernel32.dll virtualfree
unable to resolve kernel32.dll virtualalloc
unable to resolve kernel32.dll heaprealloc
unable to resolve kernel32.dll isbadwriteptr
unable to resolve kernel32.dll sethandlecount
unable to resolve kernel32.dll getstdhandle
unable to resolve kernel32.dll getfiletype
unable to resolve kernel32.dll getstartupinfoa
unable to resolve kernel32.dll exitprocess
unable to resolve kernel32.dll terminateprocess
unable to resolve kernel32.dll getcurrentprocess
unable to resolve kernel32.dll getmodulefilenamea
unable to resolve kernel32.dll freeenvironmentstringsa
unable to resolve kernel32.dll getenvironmentstrings
unable to resolve kernel32.dll freeenvironmentstringsw
unable to resolve kernel32.dll widechartomultibyte
unable to resolve kernel32.dll getenvironmentstringsw
unable to resolve kernel32.dll unhandledexceptionfilter
unable to resolve kernel32.dll heapsize
unable to resolve kernel32.dll getstringtypea
unable to resolve kernel32.dll multibytetowidechar
unable to resolve kernel32.dll getstringtypew
unable to resolve kernel32.dll getcpinfo
unable to resolve kernel32.dll getlocaleinfoa
unable to resolve kernel32.dll getacp
unable to resolve kernel32.dll getoemcp
unable to resolve kernel32.dll isbadreadptr
unable to resolve kernel32.dll isbadcodeptr
unable to resolve kernel32.dll setstdhandle
unable to resolve kernel32.dll virtualquery
unable to resolve kernel32.dll flushfilebuffers
unable to resolve kernel32.dll raiseexception

they're not in the dll-loader included, so no chance to get the plugin running is there a special trick with compiling; where does the symbols come from? i've copied the vs-goom-project-file and modified it to make it compile gforce instead.
some functions i don't know why they are needed (example lcmapstringw). perhaps i have to modify the code a little bit more :/

any suggestions?

[Butcher]

most of those should be loadable, the xbox certainly has most of those functions, maybe some fixing required for the dll loader.

[Gamester17]

Originally Posted by (questor/fused @ feb. 29 2004,09:45)

i've converted the g-force-plugin to the media-player! i can't convert it to the center, because i only have the old visual-studio * *perhaps in the near time i can get hold of the new one, but so long i have no chance to get it working. beside there are some unresolved entrys in kernel32 (and perhaps in msvcr). so there is some work left.

it's working great with all the scripts from the new version

hi questor/fused, how are you getting along porting gforce from xbmp to a xbmc dll? ps! yes you do need vs.net 7.1 (2003).
please let us all know if you run into any problems and need our assistanse, we all love to see it make the visualization competition

[questor/fused]

okay, i've finally got vs.net2003 and could compile the plugin. but there is a little problem left
the plugin needs the dll-functions "??2@yapaxi@z" (malloc) and "??3@yaxpax@z" (free). in the dllloader are these functions defined for the msvcrt.h, but not for the msvcr71.h. and the plugin imports the functions from the 7.1runtime...

i've tried simply including the functions in 7.1 like they are included in the msvcrt, but that doesn't work even with the "normal" viz-plugins. don't know why?!? i always get a access-violation.

can anyone help me with this one?

[Butcher]

hmm malloc and free should be imported as _malloc and _free. are you sure they aren't new and delete?

[questor/fused]

sorry, they are in fact new/delete

what i find strange: when i include them into the 7.1 runtime, the other plugins crash after one time activating/deactivating them, too. perhaps i'm doing something terrible wrong. including it generates a bufferover- or underrun...

doesn't use the other plugins new/delete or why doesn't they have the import-problem?

[Butcher]

i think goom has this issue - it doesn't dealloc a lot of memory (~3mb). new is a layer on top of malloc/free though so for goom i just hooked malloc/free and clean up for it.

[questor/fused]

yes, goom uses malloc/free and not new/delete!

what have i done:
downloaded sources this weekend and compiled and everything is ok.

added the following code to msvcr71.h (in core\dllloader):

#ifdef global_scope
extern "c" void dllmalloc(void);
#else
exp2dll* msvcr71_exp119 = new exp2dll("msvcr71.dll", "??2@yapaxi@z", (unsigned long)dllmalloc);
#endif
#ifdef global_scope
extern "c" void dllfree(void);
#else
exp2dll* msvcr71_exp120 = new exp2dll("msvcr71.dll", "??3@yaxpax@z", (unsigned long)dllfree);
#endif

now complete recompile, start mp3-playback with spectrum-viz (pressed blue button to start viz). everything is ok so far. but then i press the blue button again to change to the mp3-list back and i get this error
assertion failed:

_asserte(_block_type_is_valid(phead->nblockuse));

(from dbgdel.cpp)

i think there is a memover- or underrun, but don't now where/why?!?

perhaps now it's clearer to reproduce/understand what's going on....

the import "??2@yapaxi@z" and "??3@yaxpax@z" are in the msvcrt.h defined, too. but that should be no problem at all....

i think the memleak is not the problem at all, but the internal management from dllmalloc/dlldelete. does it handle new and new[]? is there a difference between them? (there should be a difference between them; red it here: http://weblogs.asp.net/oldnewthing/a.../04/67384.aspx )


thanx for your help!

[questor/fused]

ok, found the problem:
in dll.cpp are leaks detected and delete:

for (std::map<unsigned, unsigned>::iterator p = it->alloclist.begin(); p != it->alloclist.end(); ++p)
{
total += p->second;
// free((void*)p->first);
}

i think, it's because new[] can't be delete with "free". disabeling the "free" fixed the crash (but not the memleak )

edit: hm. that doesn't make much sense. both uses malloc...

[Butcher]

um doing that is a bad idea as it makes goom leak 3mb a time...