[tor-bugs] #10845 [Tor bundles/installation]: Make libeay32.dll and ssleay32.dll visible to pluggable transports

[Tor Bug Tracker & Wiki]

#10845: Make libeay32.dll and ssleay32.dll visible to pluggable transports
------------------------------------------+--------------------------
     Reporter:  dcf                       |      Owner:  erinn
         Type:  defect                    |     Status:  needs_review
     Priority:  normal                    |  Milestone:
    Component:  Tor bundles/installation  |    Version:
   Resolution:                            |   Keywords:  tbb-3.5
Actual Points:                            |  Parent ID:  #9444
       Points:                            |
------------------------------------------+--------------------------

Comment (by cypherpunks):

 > I'd like to know whether the [http://msdn.microsoft.com/en-
 us/library/office/cc842072.aspx TCHAR] stuff looks right. I used
 [http://msdn.microsoft.com/en-
 us/library/windows/desktop/dd374074%28v=vs.85%29.aspx TEXT] on string
 literals, multiplied malloc arguments by sizeof(TCHAR), and used
 [http://msdn.microsoft.com/en-us/library/78zh94ax.aspx _tcslen] and
 [http://msdn.microsoft.com/en-us/library/2ts7cx93.aspx _sntprintf] in
 place of strlen and snprintf. I don't know whether the program is getting
 compiled in _UNICODE mode or not, or how to check that.

 I think it's right to do if planned to produce ANSI and UNICODE version of
 exe for RelativeLink.c. By default (if nothing defined) it builds as ANSI,
 and only side-effect is lack of support unicode-encoded paths if different
 code page.

 If UNICODE version need then both UNICODE and _UNICODE should be defined
 before including windows specific headers (windows.h and tchar.h, as
 UNICODE for windows and _UNICODE for tchar). (At least for native mingw it
 fails to compile if only one defined.)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10845#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online