[MrC]

anybody know how to get ?_nomemory@std@@yaxxz from msvcp71.dll to work with the dll importer stuff?

cheers

[questor/fused]

what does the function do?

you have to modify the dll-loader (xbmc/cores/dllloader) to import this function(msvcr71.h) and than you have to emulate the function (emumsvcrt.cpp)

[MrC]

dunno what it does - it appears when std:tack stuff is included.

looks like i ain't gonna make the vis deadline . been working on my vis solidly all weekend to get it finished and thought converting it to a plugin would be a 10min job. looks like i need to emulate half of the stl now.

i may release it later if i can be bothered to get this plugin stuff fixed, or remove all the stl stuff from my code which will probably be easier.

anyway, good luck to everyone who has entered the compo.

cheers.

[questor/fused]

shit. that happend to me, too. thought converting should be easy... have you tried to run the thing without the function? when the dll-loader can't find a emulated routine it uses a default which simply does nothing. that way never used routines are no problem.

only reading the name i would suggest it's a function beeing called when no more memory is available. is it the only missing function?

edit:
just found:

void *__cdecl operator new(size_t size) _throw1(_std bad_alloc)
{ // try to allocate size bytes
void *p;
while ((p = malloc(size)) == 0)
if (_callnewh(size) == 0)
_std _nomemory();
return (p);
}

so _nomemory not implemented should be no problem...

[MrC]

when i was trying to track down the problem i created an empty plugin which didn't do anything except new an empty class in the start function. this worked fine, but as soon as i #included the stack stuff xbmc crashed when freeing the vis. even though i wasn't using it, it crashed just coz it was included.

i think the reason that it is crashing is that msvcr71 stuff has a default routine, like you say, but this one is a msvcp71 function so it does not get set to a default.

i also use std:tring which throws up about another 10 unresolved imports.

anyway, i think it will be easier to modify my code not to use any of the std functions than it would be to try and get it working with the import stuff. i am just a bit pissed that i have been working on my vis on and off for the past 2 months and i have fallen at the final hurdle. no complaints about the xbmc team tho, its my own fault, i shouldn't have left the plugin bit to the last minute.

seeing as i have missed the deadline anyway there is no rush to release it now so i can spend a bit more time tidying it up and adding some extra functionality - just a shame there will be no x3 at the end .

just thought - instead of buggering around with virtual machines, beat detection etc.  i could have released a vis which does nothing except flash the screen random colours and i still could have won one of the 10 prizes!  :d

bollox...

[questor/fused]

my 2cent: including the routines would it make much easier for others and depending on the functions something like that should work, too: simply map the import-function to the xbox-own routines. the std-lib is linked to the xbmc, too, so should be no big deal(hopefully ). some care has to been taken, because the emulation-layer does some housekeeping stuff (tracking memblocks for example).
perhaps i could try to help you, i've debugged the emulation-layer already a little bit. i'm no profi in it, but i've searched already my way trough it
i'm trying the empty-plugin with stack-stuff when i've left some free time (beside coding gforce-stuff )