summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorbrunsch <brunsch@ae88bc3d-4319-0410-8dbf-d08b4c9d3795>2000-11-13 11:47:10 +0000
committerbrunsch <brunsch@ae88bc3d-4319-0410-8dbf-d08b4c9d3795>2000-11-13 11:47:10 +0000
commit83370f378a1962340f965bb6e9fbec96c0a43f6f (patch)
treeeeb60bcd9629f87c6a30bb92f939998aac97c56d /docs
parent90163b24ed5faba193b69a124331bd9a596426fd (diff)
downloadATCD-83370f378a1962340f965bb6e9fbec96c0a43f6f.tar.gz
ChangeLogTag:Mon Nov 13 03:46:21 2000 Darrell Brunsch <brunsch@uci.edu>
Diffstat (limited to 'docs')
-rw-r--r--docs/CE-status.txt951
-rw-r--r--docs/wchar.txt79
2 files changed, 118 insertions, 912 deletions
diff --git a/docs/CE-status.txt b/docs/CE-status.txt
index 9ce2496f462..81a8c83b2d3 100644
--- a/docs/CE-status.txt
+++ b/docs/CE-status.txt
@@ -1,927 +1,54 @@
-The CE stuff has pretty much been all inherited by me (Darrell). Unfortunately
-I haven't been able to spend all my time on it recently, especially since
-I've been waiting for the new eMbedded Toolkit from MS.
+/**
+@page wince ACE on Windows CE status
-My plans are to report ACE to the Pocket PC Platform. The eMbedded Toolkit
-also comes with support for Windows CE 2.11 on both the Palm/PC and
-Handheld/PC, but I will probably not put too much effort into supporting
-these platforms (as the system libraries and the compilers have "issues").
+By me, Darrell Brunsch <brunsch@cs.wustl.edu>
-This release (which will be 5.1.4) will not have a working version of ACE
-on Windows CE because of last-minute issues with errno. One of the first
-things I plan to look into reimplementing the errno emulation with
-SetLastError () and GetLastError ().
+@subsection Status
-While doing this, I will also be focusing on splitting ACE into separate
-libraries, which is a slow task, but something that is very useful for
-using ACE on small devices like CE.
+Been a while since I updated this file. Where to begin. Well, as of the next
+beta kit of ACE (5.1.11), it should be compiling for the PocketPC. And it
+will have new eMbedded Visual C++ project files (*.vcw and *.vcp). Even
+though it does not have all of ACE, the stuff it has should still make it
+useful.
-Finally, once ACE is stable enough, I'll look into porting TAO over also.
+I have shifted off of Windows CE though, so the updates aren't going to come
+in as I once planned. Although I did get the library to compile and link, I
+don't have any tests ready for it.
-And just for reference, here is the old CE-status.txt file:
+I'm planning on getting the ACE tests re-ported to Windows CE again. I say
+re-ported because I'm planning on dealing with the lack of stdout a bit
+differently than Nanbor did. Instead of making a GUI front end for each
+test (which I believe is what the WindozeCE stuff is), I'm going to let them
+remain GUI-less and perhaps write an application to read the log files after
+running the tests.
+@subsection eMbedded Visual C++ Projects
--*- mode: outline; outline-regexp: " *\\[" -*-
+ACE now uses the eMbedded Visual C++ project files (instead of the older
+Windows CE Toolkit for Visual C++ project files). EVC is free from MS, either
+it can be found in the MSDN subscriptions (not free) or a CD from MS
+-- which isn't completely free either, since you still have to pay for the
+shipping and handling.
-This document presents the status of the ACE port to Windows CE. We
-present hints on writing portable code using ACE on Windows CE and
-other Win32 platforms. Moreover, we outline current unresolved
-technical issues with the port and with Windows CE development tools.
-Finally, we describe the status of all the ACE regression tests on
-Windows CE.
+@subsection Subsets
-[Hints on writing portable code using ACE]
+ACE on CE is currently split into two libraries, ace_os.dll and ace.dll.
+The ace_os library contains the files which are considered part of the ACE_OS
+subset. The ace library contains everything else. If ACE becomes more
+splittable, ace.dll will probably be broken apart even more.
- [Testing Non-Window based ACE programs]
- Rumor has it that Microsoft will provide a DOS shell in their
- next release of CE. Oh well, I made it up and there'll probably
- no DOS prompt in the future CE. All current ACE programs are
- text-based. They all need a shell to start from.
+And unlike the current *nix subsets, these two libraries are truly separate
+and do not require recompilation when the subsets required are changed.
- [Dialog Based]
- This is a collection of files that combined with any ACE
- program to run on CE. To use this template, compile your main
- project with all the cpp and rc files under $ACE_ROOT/windoezCE/.
+@subsection TAO
- The program will start by asking you the command line argument
- that you want to pass to the original ACE program. We should be
- able to get this infomation automatically if we execute the
- program from "Start -> Run...". However, that'll require us to
- implement this window using Win32 API (it's written with MFC
- classes now.) Notice that GetCommandLine is not available on
- CE.
+While it would be nice to get TAO working on CE, I doubt I'll get a chance to
+work on it before graduating. OCI has said there has been some interest in
+it, but I don't know how that is going right now.
- [Future Improvement]
+@subsection Unicode/WChar
- Get the command line argument automatically.
+ACE on WindowsCE automatically has ACE_HAS_WCHAR and ACE_USES_WCHAR turned
+on. Thus ACE_TCHAR and ACE_TEXT() are the wide char versions.
- Buffered keyboard input (stdin.)
-
- Scrollable output.
-
- [Unicode Trivia]
- Since most APIs take wide char strings as their arguments when
- strings are needed, some pre-cautions must be taken...
-
- Here are some macros that help converting string types back
- and forth based on your platform settings. Here, under CE is
- equivalent to have ACE_HAS_MOSTLY_UNICODE_APIS defined.
-
- [ASYS_TCHAR] Defined as wchar_t under CE, but as char under all
- other paltforms.
-
- [ASYS_TEXT] A macro that converts a char text to a wchar text
- only under CE.
-
- [ASYS_WIDE_STRING] A macro that converts char strings to wchar
- strings using ACE_WString only when
- ACE_HAS_MOSTLY_UNICODE_APIS is defined.
-
- [ASYS_MULTIBYTE_STRING] A macro that converts wchar strings to
- char strings using ACE_WString while
- ACE_HAS_MOSTLY_UNICODE_APIS is not defined but UNICODE is
- defined.
-
- [ASYS_ONLY_MULTIBYTE_STRING] Like ASYS_MULTIBYTE_STRING but only
- convert a string when ACE_HAS_MOSTLY_UNICODE_APIS defined and
- UNICODE not defined.
-
- [ACE_TRACE] When using ACE_TRACE macros, you don't need to use
- wide char string in it. ACE converts the char string to wchar
- string for you.
-
-[Current difficulties]
-
- [Bugs in cross compiler for SH series CPU]
-
- [Inline functions]
- are not supported at least for debug build for DLL. I have to
- un-inline _all_ inline functions in ACE to get it to work.
- Not sure if inlining works for Release version or other CPUs
- (namely, MIPS series.) It appears to work fine for x86
- emulator builds.
-
- [Lost string literals]
- The following format string in ACE_OS::ctime_r was
- misteriously replaced with garbage by SH compiler:
-
- ACE_OS::sprintf (buf, __TEXT ("%3s %3s %02d %02d:%02d:%02d %04d\n"),.....
-
- The solution for this is to define the format string in global
- namespace as:
-
- static const ASYS_TCHAR *fmtstr = __TEXT ("%3s %3s %02d %02d:%02d:%02d %04d\n");
-
- And call the sprintf as:
-
- ACE_OS::sprintf (buf, fmtstr,....);
-
- There doesn't seem to be any recognizable pattern on how this
- will happen (otherwise, I'll call this a feature.)
-
-[HPC issues]
- The only testbed we have locally is an HP 360LX. Some tests that
- use sockets must have the ethernet card installed in order to run
- successfully. If you don't, the test will either hang or worse,
- render the serial connection unusable.
-
- Sometimes, some programs will screw up the whole system
- completely. Reset button is you best friend when this happens.
-
-
-[CE Toolkit issues]
-
- [CE Toolkit]
- Using CE toolkit for C++ is simply a pain in the ass. It takes
- around 30 seconds to start up a debug session and 5+ seconds to
- single step thru a statement. It only allows remote debugging
- using the serial link but not the network. (BTW, currently, CE
- only support NE2000 compatible PCMCIA ethernet card.)
-
- [SH3 compiler]
- * The SH3 compiler does not generate string literals when they
- are used inside a function and when a precompiled header is
- also used. This problem can be seen when a variable inside a
- function is defined by initializing it to a string literal. Two
- solutions are available:
-
- - Use a global variable, if you want to initialize it to a
- string literal, or
- - Do not use precompiled headers if you initialize a
- variable, defined inside a function, with a string
- literal.
-
- * The SH3 compiler generates a fatal internal error, when
- __declspec(dllimport) is used for a class with a virtual
- function in it. To avoid the internal error, change the
- imported class to not use any virtual functions.
-
-
-[Tidbits]
-
- [Web resources]
-
- http://www.sockets.com/ws_wince.htm
-
- [FILETIME]
-
- Win32's FILETIME format can be converted to struct timeval thru a
- simple conversion. However, the tricky part here is, FILETIME is
- the total 100ns elapse since _1601_ (why the heck did Microsoft
- choose this time?) whereas POSIX timeval gives you the
- accumulated time in us since 1970. This leads to data overflow
- in timeval struture which ACE uses internally for its
- ACE_Time_Value. This also confuses ACE_OS::ctime, which, under
- CE, is a home-brewed implementation, and corrupt the whole
- program image. I don't know of a way to deal with this yet
- except adjusting for the time difference between the two
- everytime a conversion is necessary. This, of course, doesn't
- seem to be a good choice.
-
-
-
-[Status of one-button tests]
-
- [Convention of project files settings]
-
- Procedures:
-
- * Create a new "Win32 Application" project file. It should
- support the following platforms: WCE x86em, WCE MIPS, and WCE
- SH3. Notice the project location should Be under
- $ACE_ROOT/tests/WinCE.
-
- * Add the cpp file(s) along with all .cpp and .rc files under
- $ACE_ROOT/WindozeCE.
-
- * Open Project settings.
-
- * General Settings are:
- "Using MFC in a Shared DLL" for all platforms.
- Both "Intermediate files" and "Output files" should be the
- same path. They should be one of "x86emDbg", "WMIPSDbg", and
- "WCESHDbg" depend on the target platform.
-
- * "C/C++" Settings:
- Add "ACE_HAS_DLL=1", "ACE_HAS_WINCE" to preprocessor
- definitions for all target platforms.
- Set "Code Generation" -> "Use run-time library" to "Debug
- Multithreaded".
- Add to "Preprocessor" -> "Additional include directories" the
- following: "..\,..\..\,..\..\WindozeCE\".
-
- * "Link" Settings:
- Added "aced.lib" into "Input" -> "Object/library modules".
- Set "Input" -> "Additional library path" according to the
- target platform. It should one of the following:
- "..\..\ace\WCE\x86em",
- "..\..\ace\WCE\MIPS", or,
- "..\..\ace\WCE\SH".
-
- * You are all done.
-
- [Legend:]
- X - test working properly
- F - compile but doesn't work correctly.
- C - compilation trouble
- . - work pending (deferred)
- N - Not supported by CE
-
- For each test, Section [EM] describes the status of the test
- on x86 emulator. Section [SH] describes the status of the
- test under SH series machines. (I use an HP 360LX as my
- testbed.) [MIPS] information is unavailable at the moment.
-
- [N] Aio_Platform_Test
- Asynch I/O is not supported on CE.
- [X] Atomic_Op_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [X] Barrier_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [X] Basic_Types_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [X] Buffer_Stream_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [F] Conn_Test
- [EM] Runs successfully
- [SH] Hangs at halfway. (Can't have two server threads
- running at the same time.)
- I managed the test to run to completion when setting n_server = 1 and
- n_client = 4. But I don't think that considered a successful run.
- [X] Enum_Interfaces_Test
- Sort of working right.
- [EM] Report get_ip_interface error
- [SH] Report get_ip_interface error
- [N] Env_Value_Test
- [X] Future_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [X] Handle_Set_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [X] Hash_Map_Manager_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [N] IOStream_Test
- ???
- [N] MM_Shared_Memory_Test
- ???
- [X] MT_SOCK_Test
- This one takes some time.....zzzzz.....
- [EM] Runs successfully
- [SH] Runs if client threads reduced to 5.
- (And I reverted my change back, so it won't runs on our
- HP 360LX.)
- [X] Map_Manager_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [F] Mem_Map_Test
- [EM]
- [SH]
- [X] Message_Block_Test
- inline functions in auto-generated ctors.
- [EM] Runs successfully
- [SH] Runs successfully
- [F] Message_Queue_Notifications_Test
- Hang at termination.
- [EM] Runs successfully
- [SH] There appears to be more compiler bugs that affect
-this test. The notify pipe used by the reactor was not set to
-non-blocking mode and thus the test hang at termination. I was not
-able to set any break points into places I wanted. CE sucks.
- [X] Message_Queue_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [.] Naming_Test
- Registry is not added into CE yet.
- [F] Notify_Performance_Test
- [EM] Runs successfully
- [SH] ???
- [X] OrdMultiSet_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [N] Pipe_Test
- This test will have to rewriten in ACE.
- [X] Priority_Buffer_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [N] Priority_Reactor_Test
- Not supported yet.
- [X] Priority_Task_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [N] Process_Mutex_Test
- Don't know how to start a process as a console application.
- [N] Process_Strategy_Test
- Let's skip process related tests for now.
- [N] Reactor_Exceptions_Test
- Exceptions are not support on CE.
- [F] Reactor_Notify_Test
- Hang at "starting limited notifications test."
- [EM] Runs successfully
- [SH] ???
- [F] Reactor_Performance_Test
- [EM] Runs successfully
- [SH] ???
- [X] Reactor_Timer_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [F] Reactors_Test
- Hang after done_count reaches 0. Reactors were not shutting down.
- [EM] ???
- [SH]
- [X] Reader_Writer_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [X] Recursive_Mutex_Test
- The test succeeded after reducing the iteration from 100 to
- 50. It appears that windows' CEdit buffer overflowed from
- the exccessive amount of output from this test.
- [EM] Runs successfully
- [SH] Runs successfully
- [X] SOCK_Connector_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [X] SOCK_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [N] SPIPE_Test
- SPIPE is not supported yet.
- [X] SString_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [N] SV_Shared_Memory_Test
- [X] Semaphore_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [.] Service_Config_Test
- I don't have confidence on this test....
- [X] Sigset_Ops_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [X] Simple_Message_Block_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [X] TSS_Test
- TlsGetValue appearently acts differently from most Win32
- platforms. If we check the return value and the error
- code, then, ACE_OS::key_getspecific will never succeed.
- [EM] Runs successfully
- [SH] Runs successfully
- [X] Task_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [X] Thread_Manager_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [X] Thread_Mutex_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [X] Thread_Pool_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [.] Time_Service_Test
- [X] Time_Value_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [X] Timer_Queue_Test
- [EM] Runs successfully
- [SH] Runs successfully
- [.] Tokens_Test
- [N] UPIPE_SAP_Test
-
-
-[ACE File list]
- Here is a trace of ACE files about their status on CE.
- [Legend]
- (.) Defered.
- (x) Compiled successfully. (Doesn't mean it will run. ;-)
- (@) Not compile yet.
- (T) Template codes.
- (N) Not planning to support
- ( ) ???
-
- [ACE]
- [CORBA]
- (.) CORBA_Handler.cpp
- (.) CORBA_Handler.h
- (.) CORBA_Handler.i
- (.) CORBA_Ref.cpp
- (.) CORBA_Ref.h
- (.) CORBA_Ref.i
- [Collections]
- (x) Array.cpp
- (x) Array.h
- (x) Array.i
- (T) Containers.cpp
- (T) Containers.i
- (T) Containers.h
- (T) Hash_Map_Manager.cpp
- (T) Hash_Map_Manager.h
- (T) Filecache.cpp
- (T) Filecache.h
- (T) Free_List.cpp
- (T) Free_List.i
- (T) Free_List.h
- (T) Managed_Object.cpp
- (T) Managed_Object.h
- (T) Managed_Object.i
- (T) Map_Manager.cpp
- (T) Map_Manager.h
- (T) Map_Manager.i
- (x) Object_Manager.cpp
- (x) Object_Manager.i
- (x) Object_Manager.h
- (x) SString.cpp
- (x) SString.h
- (x) SString.i
- [Concurrency]
- (x) Activation_Queue.h
- (x) Activation_Queue.cpp
- (x) Atomic_Op.i
- (.) Future.h
- (.) Future.cpp
- (x) Method_Object.h
- (x) Method_Object.cpp
- (x) Process.cpp
- (x) Process.h
- (x) Process.i
- (x) Process_Manager.cpp
- (x) Process_Manager.h
- (x) Process_Manager.i
- (x) Sched_Params.cpp
- (x) Sched_Params.h
- (x) Sched_Params.i
- (x) Synch.cpp
- (x) Synch.h
- (x) Synch.i
- (x) Synch_Options.cpp
- (x) Synch_Options.h
- (x) Synch_Options.i
- (T) Synch_T.cpp
- (T) Synch_T.h
- (T) Synch_T.i
- (x) Thread.cpp
- (x) Thread.h
- (x) Thread.i
- (x) Thread_Manager.cpp
- (x) Thread_Manager.h
- (x) Thread_Manager.i
- (x) Token.cpp
- (x) Token.h
- (x) Token.i
- [Config]
- (x) config.h
- (x) Basic_Types.cpp
- (x) Basic_Types.h
- (x) Basic_Types.i
- (x) Version.h
- [Connection]
- (T) Acceptor.cpp
- (T) Acceptor.h
- (T) Acceptor.i
- (.) Asynch_Acceptor.cpp
- (.) Asynch_Acceptor.h
- (.) Asynch_Acceptor.i
- (x) Asynch_IO.cpp
- (x) Asynch_IO.h
- (x) Asynch_IO.i
- (T) Connector.cpp
- (T) Connector.h
- (T) Connector.i
- (T) Dynamic_Service.cpp
- (T) Dynamic_Service.h
- (T) Dynamic_Service.i
- (x) Strategies.cpp
- (x) Strategies.h
- (x) Strategies.i
- (T) Strategies_T.cpp
- (T) Strategies_T.h
- (T) Strategies_T.i
- (T) Svc_Handler.cpp
- (T) Svc_Handler.h
- (T) Svc_Handler.i
- [IPC]
- [IO_SAP]
- (x) IO_SAP.cpp
- (x) IO_SAP.h
- (x) IO_SAP.i
- [DEV_SAP]
- (N) DEV.cpp
- (N) DEV.h
- (N) DEV.i
- (N) DEV_Connector.cpp
- (N) DEV_Connector.h
- (N) DEV_Connector.i
- (N) DEV_IO.cpp
- (N) DEV_IO.h
- (N) DEV_IO.i
- (N) TTY_IO.cpp
- (N) TTY_IO.h
- [FILE_SAP]
- (.) FILE.cpp
- (.) FILE.h
- (.) FILE.i
- (.) FILE_Connector.cpp
- (.) FILE_Connector.h
- (.) FILE_Connector.i
- (.) FILE_IO.cpp
- (.) FILE_IO.h
- (.) FILE_IO.i
- [IPC_SAP]
- (x) IPC_SAP.cpp
- (x) IPC_SAP.h
- (x) IPC_SAP.i
- [Addr]
- (x) Addr.cpp
- (x) Addr.h
- (x) Addr.i
- (N) DEV_Addr.cpp
- (N) DEV_Addr.h
- (N) DEV_Addr.i
- (.) FILE_Addr.cpp
- (.) FILE_Addr.h
- (.) FILE_Addr.i
- (x) INET_Addr.cpp
- (x) INET_Addr.h
- (x) INET_Addr.i
- (.) SPIPE_Addr.cpp
- (.) SPIPE_Addr.h
- (.) SPIPE_Addr.i
- (N) UNIX_Addr.cpp
- (N) UNIX_Addr.h
- (N) UNIX_Addr.i
- (.) UPIPE_Addr.h
- [FIFO_SAP]
- (.) FIFO.cpp
- (.) FIFO.h
- (.) FIFO.i
- (.) FIFO_Recv.cpp
- (.) FIFO_Recv.h
- (.) FIFO_Recv.i
- (.) FIFO_Recv_Msg.cpp
- (.) FIFO_Recv_Msg.h
- (.) FIFO_Recv_Msg.i
- (.) FIFO_Send.cpp
- (.) FIFO_Send.h
- (.) FIFO_Send.i
- (.) FIFO_Send_Msg.cpp
- (.) FIFO_Send_Msg.h
- (.) FIFO_Send_Msg.i
- [SOCK_SAP]
- ( ) LOCK_SOCK_Acceptor.cpp
- ( ) LOCK_SOCK_Acceptor.h
- ( ) LSOCK.cpp
- ( ) LSOCK.h
- ( ) LSOCK.i
- ( ) LSOCK_Acceptor.cpp
- ( ) LSOCK_Acceptor.h
- ( ) LSOCK_Acceptor.i
- ( ) LSOCK_CODgram.cpp
- ( ) LSOCK_CODgram.h
- ( ) LSOCK_CODgram.i
- ( ) LSOCK_Connector.cpp
- ( ) LSOCK_Connector.h
- ( ) LSOCK_Connector.i
- ( ) LSOCK_Dgram.cpp
- ( ) LSOCK_Dgram.h
- ( ) LSOCK_Dgram.i
- ( ) LSOCK_Stream.cpp
- ( ) LSOCK_Stream.h
- ( ) LSOCK_Stream.i
- (x) SOCK.cpp
- (x) SOCK.h
- (x) SOCK.i
- (x) SOCK_Acceptor.cpp
- (x) SOCK_Acceptor.h
- (x) SOCK_Acceptor.i
- (x) SOCK_CODgram.cpp
- (x) SOCK_CODgram.h
- (x) SOCK_CODgram.i
- (x) SOCK_Connector.cpp
- (x) SOCK_Connector.h
- (x) SOCK_Connector.i
- (x) SOCK_Dgram.cpp
- (x) SOCK_Dgram.h
- (x) SOCK_Dgram.i
- (x) SOCK_Dgram_Bcast.cpp
- (x) SOCK_Dgram_Bcast.h
- (x) SOCK_Dgram_Bcast.i
- (x) SOCK_Dgram_Mcast.cpp
- (x) SOCK_Dgram_Mcast.h
- (x) SOCK_Dgram_Mcast.i
- (x) SOCK_IO.cpp
- (x) SOCK_IO.h
- (x) SOCK_IO.i
- (x) SOCK_Stream.cpp
- (x) SOCK_Stream.h
- (x) SOCK_Stream.i
- [SPIPE_SAP]
- (.) SPIPE.cpp
- (.) SPIPE.h
- (.) SPIPE.i
- (.) SPIPE_Acceptor.cpp
- (.) SPIPE_Acceptor.h
- (.) SPIPE_Acceptor.i
- (.) SPIPE_Connector.cpp
- (.) SPIPE_Connector.h
- (.) SPIPE_Connector.i
- (.) SPIPE_Stream.cpp
- (.) SPIPE_Stream.h
- (.) SPIPE_Stream.i
- [TLI_SAP]
- (N) TLI.cpp
- (N) TLI.h
- (N) TLI.i
- (N) TLI_Acceptor.cpp
- (N) TLI_Acceptor.h
- (N) TLI_Acceptor.i
- (N) TLI_Connector.cpp
- (N) TLI_Connector.h
- (N) TLI_Connector.i
- (N) TLI_Stream.cpp
- (N) TLI_Stream.h
- (N) TLI_Stream.i
- [UPIPE_SAP]
- (N) UPIPE_Acceptor.cpp
- (N) UPIPE_Acceptor.h
- (N) UPIPE_Acceptor.i
- (N) UPIPE_Connector.cpp
- (N) UPIPE_Connector.h
- (N) UPIPE_Connector.i
- (N) UPIPE_Stream.cpp
- (N) UPIPE_Stream.h
- (N) UPIPE_Stream.i
- [Utils]
- (N) IOStream.cpp // CE doesn't have iostream stuff
- (N) IOStream.h
- (N) IOStream_T.cpp
- (N) IOStream_T.h
- (N) IOStream_T.i
- (x) Pipe.cpp
- (x) Pipe.h
- (x) Pipe.i
- (x) Signal.cpp
- (x) Signal.h
- (x) Signal.i
- [Logging and Tracing]
- (x) Dump.cpp
- (x) Dump.h
- (x) Dump_T.cpp
- (T) Dump_T.h
- (T) Log_Msg.cpp
- (x) Log_Msg.h
- (x) Log_Msg.i
- (x) Log_Priority.h
- (x) Log_Record.cpp
- (x) Log_Record.h
- (x) Log_Record.i
- (x) Trace.cpp
- (x) Trace.h
- (x) Trace.i
- [Memory]
- [Mem_Map]
- (x) Mem_Map.cpp
- (x) Mem_Map.h
- (x) Mem_Map.i
- [Shared_Malloc]
- (x) Malloc.cpp
- (x_) Malloc.h
- (x) Malloc.i
- (T) Malloc_T.cpp
- (T) Malloc_T.h
- (T) Malloc_T.i
- (x) Memory_Pool.cpp
- (x_) Memory_Pool.h
- (x) Memory_Pool.i
- [Shared_Memory]
- ( ) Shared_Memory.h
- ( ) Shared_Memory_MM.cpp
- ( ) Shared_Memory_MM.h
- ( ) Shared_Memory_MM.i
- ( ) Shared_Memory_SV.cpp
- ( ) Shared_Memory_SV.h
- ( ) Shared_Memory_SV.i
- [Utils]
- (x) Obstack.cpp
- (x) Obstack.h
- (@) Read_Buffer.cpp
- (@) Read_Buffer.h
- (@) Read_Buffer.i
- [Misc]
- (x) ARGV.cpp
- (x) ARGV.h
- (x) ARGV.i
- (T) Auto_Ptr.cpp
- (T) Auto_Ptr.h
- (T) Auto_Ptr.i
- (x) Dynamic.cpp
- (x) Dynamic.h
- (x) Dynamic.i
- (x) Get_Opt.cpp
- (x) Get_Opt.h
- (x) Get_Opt.i
- (.) Registry.cpp
- (.) Registry.h
- (T) Singleton.cpp
- (T) Singleton.h
- (T) Singleton.i
- (x) System_Time.cpp
- (x) System_Time.h
- [Name_Service]
- (.) Local_Name_Space.cpp
- (.) Local_Name_Space.h
- (.) Local_Name_Space_T.cpp
- (.) Local_Name_Space_T.h
- (.) Name_Options.cpp
- (.) Name_Options.h
- (.) Name_Proxy.cpp
- (.) Name_Proxy.h
- (.) Name_Request_Reply.cpp
- (.) Name_Request_Reply.h
- (.) Name_Space.cpp
- (.) Name_Space.h
- (.) Naming_Context.cpp
- (.) Naming_Context.h
- (.) Registry_Name_Space.cpp
- (.) Registry_Name_Space.h
- (.) Remote_Name_Space.cpp
- (.) Remote_Name_Space.h
- [OS Adapters]
- (x) ACE.cpp
- (x) ACE.h
- (x) ACE.i
- (x) OS.cpp
- (x) OS.h
- (x) OS.i
- [Reactor]
- (x) Event_Handler.cpp
- (x) Event_Handler.h
- (x) Event_Handler.i
- (T) Event_Handler_T.cpp
- (T) Event_Handler_T.h
- (T) Event_Handler_T.i
- (x) Handle_Set.cpp
- (x) Handle_Set.h
- (x) Handle_Set.i
- ( ) Priority_Reactor.cpp
- ( ) Priority_Reactor.i
- ( ) Priority_Reactor.h
- ( ) Proactor.h
- ( ) Proactor.i
- ( ) Proactor.cpp
- (x) Reactor.cpp
- (x) Reactor.h
- (x) Reactor.i
- (x) Reactor_Impl.h
- (x) Select_Reactor.cpp
- (x) Select_Reactor.h
- (x) Select_Reactor.i
- (@) WFMO_Reactor.cpp
- (@) WFMO_Reactor.h
- (@) WFMO_Reactor.i
- (x) XtReactor.cpp
- (x) XtReactor.h
- [Service_Configurator]
- (x) Parse_Node.cpp
- (x) Parse_Node.h
- (x) Parse_Node.i
- (x) Service_Config.cpp
- (x) Service_Config.h
- (x) Service_Config.i
- (x) Service_Manager.cpp
- (x) Service_Manager.h
- (x) Service_Manager.i
- (x) Service_Object.cpp
- (x) Service_Object.h
- (x) Service_Object.i
- (x) Service_Repository.cpp
- (x) Service_Repository.h
- (x) Service_Repository.i
- (x) Service_Types.cpp
- (x) Service_Types.i
- (x) Service_Types.h
- (x) Shared_Object.cpp
- (x) Shared_Object.h
- (x) Shared_Object.i
- (x) Svc_Conf.h
- (x) Svc_Conf_l.cpp
- (x) Svc_Conf_y.cpp
- [Streams]
- (x) IO_Cntl_Msg.cpp
- (x_) IO_Cntl_Msg.h
- (x) IO_Cntl_Msg.i
- (x) Message_Block.cpp
- (x) Message_Block.h
- (x) Message_Block.i
- (T) Message_Queue.cpp
- (T) Message_Queue.h
- (T) Message_Queue.i
- (T) Module.cpp
- (T) Module.h
- (T) Module.i
- (.) Multiplexor.cpp
- (.) Multiplexor.h
- (.) Multiplexor.i
- (T) Stream.cpp
- (T) Stream.h
- (T) Stream.i
- (T) Stream_Modules.cpp
- (T) Stream_Modules.h
- (T) Stream_Modules.i
- (x) Task.cpp
- (x) Task.h
- (x) Task.i
- (T) Task_T.cpp
- (T) Task_T.h
- (T) Task_T.i
- [System_V_IPC]
- [System_V_Message_Queues]
- ( ) SV_Message.cpp
- ( ) SV_Message.h
- ( ) SV_Message.i
- ( ) SV_Message_Queue.cpp
- ( ) SV_Message_Queue.h
- ( ) SV_Message_Queue.i
- ( ) Typed_SV_Message.cpp
- ( ) Typed_SV_Message.h
- ( ) Typed_SV_Message.i
- ( ) Typed_SV_Message_Queue.cpp
- ( ) Typed_SV_Message_Queue.h
- ( ) Typed_SV_Message_Queue.i
- [System_V_Semaphores]
- ( ) SV_Semaphore_Complex.cpp
- ( ) SV_Semaphore_Complex.h
- ( ) SV_Semaphore_Complex.i
- ( ) SV_Semaphore_Simple.cpp
- ( ) SV_Semaphore_Simple.h
- ( ) SV_Semaphore_Simple.i
- [System_V_Shared_Memory]
- ( ) SV_Shared_Memory.cpp
- ( ) SV_Shared_Memory.h
- ( ) SV_Shared_Memory.i
- [Timers]
-
- (x) High_Res_Timer.cpp
- (x) High_Res_Timer.h
- (x) High_Res_Timer.i
- (x) Profile_Timer.cpp
- (x) Profile_Timer.h
- (x) Profile_Timer.i
- (.) Time_Request_Reply.cpp
- (.) Time_Request_Reply.h
- (x) Time_Value.h
- (x) Timer_Hash.cpp
- (x) Timer_Hash.h
- (T) Timer_Hash_T.cpp
- (T) Timer_Hash_T.h
- (x) Timer_Heap.cpp
- (x) Timer_Heap.h
- (x) Timer_Heap.i
- (T) Timer_Heap_T.cpp
- (T) Timer_Heap_T.h
- (T) Timer_Heap_T.i
- (x) Timer_List.cpp
- (x) Timer_List.h
- (x) Timer_List.i
- (T) Timer_List_T.cpp
- (T) Timer_List_T.h
- (T) Timer_List_T.i
- (x) Timer_Queue.cpp
- (x) Timer_Queue.h
- (x) Timer_Queue.i
- (T) Timer_Queue_Adapters.cpp
- (T) Timer_Queue_Adapters.h
- (T) Timer_Queue_Adapters.i
- (T) Timer_Queue_T.cpp
- (T) Timer_Queue_T.h
- (T) Timer_Queue_T.i
- (x) Timer_Wheel.cpp
- (x) Timer_Wheel.h
- (x) Timer_Wheel.i
- (T) Timer_Wheel_T.cpp
- (T) Timer_Wheel_T.h
- (T) Timer_Wheel_T.i
- [Token_Service]
- (x) Local_Tokens.cpp
- (x) Local_Tokens.h
- (x) Local_Tokens.i
- (.) Remote_Tokens.cpp
- (.) Remote_Tokens.h
- (.) Remote_Tokens.i
- (.) Token_Collection.cpp
- (.) Token_Collection.h
- (.) Token_Collection.i
- (x) Token_Manager.cpp
- (x) Token_Manager.h
- (x) Token_Manager.i
- (.) Token_Request_Reply.cpp
- (.) Token_Request_Reply.h
- (.) Token_Request_Reply.i
- (.) Token_Invariants.h
- (.) Token_Invariants.i
- (.) Token_Invariants.cpp
+*/ \ No newline at end of file
diff --git a/docs/wchar.txt b/docs/wchar.txt
new file mode 100644
index 00000000000..6ad32cb45fc
--- /dev/null
+++ b/docs/wchar.txt
@@ -0,0 +1,79 @@
+/**
+@page wchar Wide Character/Unicode support in ACE
+
+Here's a first stab at some sort of documentation for the magic wchar stuff
+in ACE.
+
+@subsection Overview
+
+There are three different wchar configurations that ACE can use. These are
+no support mode, regular support mode, and full support mode (well, those are
+the best names I can come up with for now).
+
+@subsection No Support
+
+By default, ACE will not use wchar_t at all. This is for platforms where
+wchar_t does not exist or support for it is pretty flakey.
+
+@subsection Regular Support
+
+If ACE_HAS_WCHAR is defined, then ACE classes will be expanded to have extra
+methods which take in wchar_t strings. Note that all the methods available
+with No Support are also available here. This is the default in Windows
+right now, and has been tested to work on Linux and VxWorks (well, only been
+tested to compile/link of VxWorks).
+
+@subsection Full Support
+
+Full support is turned on if ACE_HAS_WCHAR and ACE_USES_WCHAR are defined.
+Like Regular Support, both char and wchar_t versions of some methods are
+available, but unlike Regular Support, other methods that have char arguments
+or return values may have wchar_t arguments or return values.
+
+This has only been tested in Windows, and is the default for Windows CE.
+
+@subsection Other Important Macros
+
+In addition to the ACE_HAS_WCHAR and ACE_USES_WCHAR mentioned above, there
+are several other macros that are important when using wide character support
+in ACE.
+
+These other macros are used in code to conditionally switch between char and
+wchar_t. ACE_TCHAR is a char normally and wchar_t when ACE_USES_WCHAR is
+defined. ACE_TEXT ("foo") expands to "foo" normally and L"foo" when
+ACE_USES_WCHAR is defined.
+
+ACE_TEXT_CHAR_TO_TCHAR and ACE_TEXT_WCHAR_TO_TCHAR are used when a string
+that is always a char or wchar_t string needs to be converted to a ACE_TCHAR
+string. On the same note, ACE_TEXT_ALWAYS_CHAR is used when a string is
+ACE_TCHAR * and needs to be a char * string.
+
+ACE_TEXT_WIDE ("foo") is unique in that it always maps to L"foo". It is not
+a conditional macro.
+
+Finally, on Windows there are a bunch of ACE_TEXT_Apicall type macros which
+are used to choose the correct version of a Win32 API function depending on
+ACE_USES_WCHAR. I'm hoping to remove these by adding a new ACE_OS_Win32
+class to perform the same task, but until then these ugly macros get the job
+done.
+
+@subsection Relation to Win32's UNICODE and _UNICODE macros
+
+It used to be that in previous versions of ACE that the Win32 macros affected
+ACE in some way. This has been all removed in favor of the ACE_USES_WCHAR
+and ACE_HAS_WCHAR macros. Along with this, the definition of some of the
+Win32 string types (LPTSTR, LPCSTR, etc.) have been also removed. Since this
+isn't a direct concern of ACE, they will have to be defined separately if
+they are needed on non-Win32 platforms.
+
+The way I'd recommend doing this is to add the typdefs to config.h.
+
+@subsection Legacy Support
+
+Most of the old macros (ACE_HAS_UNICODE, ACE_HAS_MOSTLY_UNICODE_APIS) are
+ignored by default by ACE, since the new macros replaced them. If
+ACE_LEGACY_MODE is defined, there is an attempt to map them to the new scheme
+by just ACE_HAS_UNICODE == ACE_HAS_WCHAR and ACE_HAS_MOSTLY_UNICODE_APIS ==
+ACE_USES_WCHAR.
+
+*/ \ No newline at end of file