[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #10845 [Tor bundles/installation]: Make libeay32.dll and ssleay32.dll visible to pluggable transports
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs