[Bf-committers] BlenderCE - Guardedalloc...

[Salvatore Russo]

Hallo,
 
Your warning show me that I am not taking the good direction! I will lose the control about what I am doing if I change so deeply the code 
 and it will never work :=(
 
I think I misunderstood this Unicode compability when I worked with Ghost
 But it is probably because Ghost uses Window API a lot.
 
Some points where I am confused:
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
 
 
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)