]>
Commit | Line | Data |
---|---|---|
d02b48c6 RE |
1 | The Microsoft World. |
2 | ||
3 | The good news, to build SSLeay for the Microsft World | |
4 | ||
5 | Windows 3.1 DLL's | |
6 | perl Configure VC-WIN16 | |
7 | nmake -f ms\w31dll.mak | |
8 | ||
9 | Windows NT/95 DLL's | |
10 | perl Configure VC-WIN32 | |
11 | nmake -f ms\ntdll.mak | |
12 | ||
13 | Now the bad news | |
14 | All builds were done using Microsofts Visual C++ 1.52c and [45].x. | |
15 | If you are a borland person, you are probably going to have to help me | |
16 | finish the stuff in util/pl/BC*pl | |
17 | ||
18 | All builds were made under Windows NT - this means long filenames, so | |
19 | you may have problems under Windows 3.1 but probably not under 95. | |
20 | ||
21 | Because file pointers don't work in DLL's under Windows 3.1 (well at | |
22 | least stdin/stdout don't and I don't like having to differentiate | |
23 | between these and other file pointers), I now use the BIO file-pointer | |
24 | module, which needs to be linked into your application. You can either | |
25 | use the memory buffer BIO for IO, or compile bss_file.c into your | |
26 | application, it is in the apps directory and is just a copy of | |
27 | crypto/buffer/bss_file.c with #define APPS_WIN16 added. | |
28 | I have not yet automated the makefile to automatically copy it into 'out' | |
29 | for a win 3.1 build.... | |
30 | ||
31 | All callbacks passed into SSLeay for Windows 3.1 need to be of type | |
32 | _far _loadds. | |
33 | ||
34 | I don't support building with the pascal calling convention. | |
35 | ||
36 | The DLL and static builds are large memory model. | |
37 | ||
38 | To build static libraries for NT/95 or win 3.1 | |
39 | ||
40 | perl util/mk1mf.pl VC-WIN32 > mf-stat.nt | |
41 | perl util/mk1mf.pl VC-WIN16 > mf-stat.w31 | |
42 | for DLL's | |
43 | perl util/mk1mf.pl dll VC-WIN32 > mf-dll.nt | |
44 | perl util/mk1mf.pl dll VC-WIN16 > mf-dll.w31 | |
45 | ||
46 | Again you will notice that if you dont have perl, you cannot do this. | |
47 | ||
48 | Now the next importaint issue. Running Configure! | |
49 | I have small assember code files for critical big number library operation | |
50 | in crypto/bn/asm. There is, asm code, object files and uuencode | |
51 | object files. They are | |
52 | x86nt32.asm - 32bit flat memory model assember - suitable Win32 | |
53 | x86w16.asm - 16bit assember - used in the msdos build. | |
54 | x86w32.asm - 32bit assember, win 3.1 segments, used for win16 build. | |
55 | ||
56 | If you feel compelled to build the 16bit maths routines in the windows 3.1 | |
57 | build, | |
58 | perl Configure VC-W31-16 | |
59 | perl util/mk1mf.pl dll VC-W31-16 > mf-dll.w31 | |
60 | ||
61 | If you hate assember and don't want anything to do with it, | |
62 | perl util/mk1mf.pl no-asm VC-WIN16 > mf-dll.w31 | |
63 | will work for any of the makefile generations. | |
64 | ||
65 | There are more options to mk1mf.pl but these all leave the temporary | |
66 | files in 'tmp' and the output files in 'out' by default. | |
67 | ||
68 | The NT build is done for console mode. | |
69 | ||
70 | The Windows 3.1 version of SSLeay uses quickwin, the interface is ugly | |
71 | but it is better than nothing. If you want ugly, try doing anything | |
72 | that involves getting a password. I decided to be ugly instead of | |
73 | echoing characters. For Windows 3.1 I would just sugest using the | |
74 | msdos version of the ssleay application for command line work. | |
75 | The QuickWin build is primarily for testing. | |
76 | ||
77 | For both NT and Windows 3.1, I have not written the code so that | |
78 | s_client, s_server can take input from the keyboard. You can happily | |
79 | start applications up in separate windows, watch them handshake, and then sit | |
80 | there for-ever. I have not had the time to get this working, and I've | |
81 | been able to test things from a unix box to the NT box :-). | |
82 | Try running ssleay s_server on the windows box | |
83 | (with either -cert ../apps/server.pem -www) | |
84 | and run ssleay s_time from another window. | |
85 | This often stuffs up on Windows 3.1, but I'm not worried since this is | |
86 | probably a problem with my demo applications, not the libraries. | |
87 | ||
88 | After a build of one of the version of microsoft SSLeay, | |
89 | 'cd ms' and then run 'test'. This should check everything out and | |
90 | even does a trial run of generating certificates. | |
91 | 'test.bat' requires that perl be install, you be in the ms directory | |
92 | (not the test directory, thats for unix so stay out :-) and that the | |
93 | build output directory be ../out | |
94 | ||
95 | On a last note, you will probably get division by zero errors and | |
96 | stuff after a build. This is due to your own inability to follow | |
97 | instructions :-). | |
98 | ||
99 | The reasons for the problem is probably one of the following. | |
100 | ||
101 | 1) You did not run Configure. This is critical for windows 3.1 when | |
102 | using assember. The values in crypto/bn/bn.h must match the | |
103 | ones requred for the assember code. (remember that if you | |
104 | edit crypto/bn/bn.h by hand, it will be clobered the next time | |
105 | you run Configure by the contents of crypto/bn/bn.org). | |
106 | SSLeay version -o will list the compile options. | |
107 | For VC-WIN32 you need bn(64,32) or bn(32,32) | |
108 | For VC-W31-32/VC-WIN16 you need bn(32,32) | |
109 | For VC-W31-16 you need bn(32,16) or bn(16,16) | |
110 | For VC-MSDOS you need bn(32,16) or bn(16,16). | |
111 | ||
112 | The first number will be 2 times bigger than the second if | |
113 | BN_LLONG is defined in bn.h and the size of the second number | |
114 | depends on the 'bits' defined at the start of bn.h. Have a | |
115 | look, it's all reasonably clear. | |
116 | If you want to start messing with 8 bit builds and things like | |
117 | that, build without the assember by re-generating a makefile | |
118 | via 'perl util/mk1mf.pl no-asm'. | |
119 | 2) You tried to build under MS-DOS or Windows 3.1 using the /G3 | |
120 | option. Don't. It is buggy (thats why you just got that | |
121 | error) and unless you want to work out which optimising flag | |
122 | to turn off, I'm not going to help you :-). I also noticed | |
123 | that code often ran slower when compiled with /G3. | |
124 | 3) Under NT/95, malloc goes stupid. You are probably linking with | |
125 | the wrong library, there are problems if you mix the threaded | |
126 | and non-threaded libraries (due to the DLL being staticly | |
127 | linked with one and the applicaion using another. | |
128 | ||
129 | Well hopefully thats most of the MS issues handled, see you in ssl-users :-). | |
130 | ||
131 | eric 30-Aug-1996 | |
132 | ||
133 | SSLeay 0.6.5 | |
134 | For Windows 95/NT, add CRYPTO_malloc_init() to your program before any | |
135 | calls to the SSLeay libraries. This function will insert callbacks so that | |
136 | the SSLeay libraries will use the same malloc(), free() and realloc() as | |
137 | your application so 'problem 3)' mentioned above will go away. | |
138 | ||
139 | There is now DES assember for Windows NT/95. The file is | |
140 | crypto/des/asm/win32.asm and replaces crypto/des/des_enc.c in the build. | |
141 | ||
142 | There is also Blowfish assember for Windows NT/95. The file is | |
143 | crypto/bf/asm/win32.asm and replaces crypto/bf/bf_enc.c in the build. | |
144 | ||
145 | eric 25-Jun-1997 | |
146 |