[Bf-committers] BlenderCE - Guardedalloc...

[Ton Roosendaal]

Hi,

> 1) Char and all associated function (str*, sprint, etc) are defined  
> for WinCE so they should work! But how…
> 2) But all documentation that I read say that Pocketpc is aUnicode  
> environment… so what is a char or “blabla” in a Unicode environment…
> 3) When I define a project, the Unicode definition is ever predefined.  
> I will see what happen if I don’t use it…
> 4) When I run the debugger, all variable in char are written in a very  
> buggy way… but it is maybe because EVC is considering them as Unicode…

You best seek help on winCE forums I guess. All I know is that unicode  
and 1-byte chars should be able to live happily next to each other.

-Ton-


>
> I will work on Ghost again. Now that I know that it can work on a  
> pocketpc and what he does, I will try to make it work changing only  
> few thinks and using the original char and only “local convertion”  
> when it is necessary for the API…
>
> I think you are right…
>
> I will let you know :=)
> Salvatore
>
>
>> Hi,
>>
>> I can't believe the WindowsCE API doesn't support the the C type
>> 'unsigned char' at all. That would be ridiculous! Changing all chars  
>> in
>> Blender into 2 byte unicode stuff is just asking for getting into deep
>> troubles... don't give you any chance of getting running code then.
>>
>> -Ton-
>>
>> On 9 Aug, 2005, at 13:37, Salvatore Russo wrote:
>>
>>> Hallo,
>>>
>>> Sorry to ever ask you some clarification. I hope it is the right  
>>> place
>>> to do it. I also continue my post in the forum (in news).
>>>
>>> I am facing difficulties with the library Guardedalloc.
>>>
>>> In the Blender code, I transformed ALL char in wchar_t, changed all
>>> string "blabla" with L"blabla", changed the memory allocation because
>>> wchar_t are 2 bytes and not 1 as char (ex: malloc(string) becomes
>>> malloc(string*sizeof(wchar_T)), I changed also calloc, also memcpy  
>>> and
>>> memmove in wmemcpy and wmemmove), I also changed all str* functions
>>> with wcs* functions... I hope I forgot nothing! I will discover that  
>>> in
>>> the debugging process.
>>>
>>> But for the Guardedalloc library( one single mallocn.c file), I feel
>>> losted. This library is managing deep memory management... I can here
>>> not do think like that...
>>>
>>> I converted this file in Unicode but memory management is very
>>> sensitive and I have to say that now, I don´t know how to continue...
>>> there is a test file for mallocn.c but it is not working... it  
>>> crashes
>>> ever...
>>>
>>> My version of mallocn.c has problem. And I don´t know where to find
>>> information to correct it... And I will not be able to go further  
>>> before
>>> this guardedalloc library is working perfectly.
>>>
>>> For example, here some example of mallocn.c where I am not so
>>> confident:
>>>
>>> #if defined( __sgi) || defined (__sun) || defined (__sun__) ||  
>>> defined
>>> (__sparc) || defined (__sparc__) || defined (__PPC__) || defined
>>> (__APPLE__)
>>> #define MAKE_ID(a,b,c,d) ( (int)(a)<<24 | (int)(b)<<16 | (c)<<8 |  
>>> (d) )
>>> #else
>>> #define MAKE_ID(a,b,c,d) ( (int)(d)<<24 | (int)(c)<<16 | (b)<<8 |  
>>> (a) )
>>> #endif
>>>
>>> //WinCE in UNICODE
>>> #define MEMTAG1 MAKE_ID(L'M', L'E', L'M', L'O')
>>> #define MEMTAG2 MAKE_ID(L'R', L'Y', L'B', L'L')
>>> #define MEMTAG3 MAKE_ID(L'O', L'C', L'K', L'!')
>>> #define MEMFREE MAKE_ID(L'F', L'R', L'E', L'E')
>>>
>>> #define MEMNEXT(x) ((MemHead *)(((wchar_t *) x) - ((wchar_t *) &
>>> (((MemHead *)0)->next))))
>>>
>>> This 0? A Unicode string finish with two 0... can it be a problem  
>>> here?
>>>
>>> or this function:
>>>
>>> void *MEM_mallocN(unsigned int len, wchar_t *str)
>>> {
>>> MemHead *memh;
>>> MemTail *memt;
>>>
>>> if(sizeof(long)==8)
>>> len = (len + 3 ) & ~3; /* eenheden van 4 */
>>> else
>>> len = (len + 7 ) & ~7; /* eenheden van 8 */
>>>
>>> //WinCE in UNICODE!
>>> memh= (MemHead
>>> *)malloc((len+sizeof(MemHead)+sizeof(MemTail))*sizeof(wchar_t));
>>>
>>> if(memh!=0) {
>>> memh->tag1 = MEMTAG1;
>>> memh->name = str;
>>> memh->nextname = 0;
>>> memh->len = len;
>>> /* memh->level = 0; */
>>> memh->tag2 = MEMTAG2;
>>>
>>> memt = (MemTail *)(((wchar_t *) memh) + sizeof(MemHead) +
>>> len);
>>> memt->tag3 = MEMTAG3;
>>>
>>> addtail(membase,&memh->next);
>>> if (memh->next) memh->nextname = MEMNEXT(memh->next)->name;
>>>
>>> totblock++;
>>> mem_in_use += len;
>>> return (++memh);
>>> }
>>> if (err_stream) fwprintf(err_stream, L"Malloc returns nill:
>>> len=%d in %s\n",len,str);
>>> return 0;
>>> }
>>>
>>> what are these numbers associated to len ??
>>>
>>> Has someone an idea about the best method to make this gardedalloc
>>> library work on pocketpc :=) Or documentation where I can find
>>> relevant information to go further :=) ?
>>>
>>> Thanks a lot for your help,
>>>
>>> Salvatore
>>>
>>>
>>>
>>> Accédez au courrier électronique de La Poste : www.laposte.net ;
>>> 3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)
>>>
>>>
>>>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at projects.blender.org
>>> http://projects.blender.org/mailman/listinfo/bf-committers
>>>
>>>
>> ---------------------------------------------------------------------- 
>> --
>> --
>> Ton Roosendaal Blender Foundation ton at blender.org
>> http://www.blender.org
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at projects.blender.org
>> http://projects.blender.org/mailman/listinfo/bf-committers
>
> Accédez au courrier électronique de La Poste : www.laposte.net ;
> 3615 LAPOSTENET (0,34€/mn) ; tél : 08 92 68 13 50 (0,34€/mn)
>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton at blender.org  
http://www.blender.org