There are a lot of articles about Unicode in Delphi
Porting of components is no different from porting applications.
Find and read them. Really do.
You'd be hit by PChar -> PAnsiChar/PWideChar ambuiguity, especially if you work in {$T-} mode. Check that your pointers are typed when compiling.
You'd be hit if you did not multiply on Sizeof(char) when allocating buffers or moving raw data my move
procedure.
You'd better to search for ambiguous types - char, pchar, string - and remove them, explicitly substituting them by WideChar/PWideChar/UnicodeString or AnsiChar/PAnsiChar/AnsiString depending on context. Thus you would both learn where type transitions may occur and perhaps make compiler so type-checking for you. ShortStirng type (string[255]
used bye TreeNT) is non-Unicode by definition. Take care everyplace when you access it.
You'd be hit if you make direct imports from Windows DLLs and specified "A" at the Windows functions name. That can easily result in ANSI function getting unexpected UTF-16 data.
Try to search if someone already did it. For example http://code.google.com/p/keynote-nf/source/browse/trunk/3rd_party/treent/TreeNT.pas - but this ended in 2007, before Unicode in Delphi RTL.