> Hi mads, > > The > > OpenSSL/ms/ > > directory contains a simple 16all.bat batchfile (you need perl installed on your > development system) which Might Just Work(tm). (At least it worked for older > versions) > > Digging in my memory (which has leaks ;-) ) I recall porting OpenSSL to a 16-bit > (embedded & not supported by OpenSSL) intel environment (Visual C 1.52 and other > 'fine' compilers at the time; urgh... <wipe> ) like this: > > - extract the tar ball on a UNIX machine > - configure (don't bother with the non-UNIX environment yet) > - run a test, just for a positive start (it works now) > - use the symhacks.h headerfile as a master for a little shell+sed script, which > would process all those huge names in the sources and make them smaller. > - run that script through a 'find -exec' to process all sources > - make sure the 'new' stuff compiles (does it still work on your UNIX box?) > - tar the whole shebang and carry it over to the FAT/MSDOS-crippled system > - extract there and continue; make sure you have the relevant config files fixed > > or try that 16all.bat file and don't sweat if it doesn't work from scratch; I > recall I had to tweak e_os.h quite a bit to make anything compile on my embedded > systems with crippled RTLs. > > ---------------------- > > > Have any one done this? Is there an easier way? the perl scripts > > available for configuring the package doesn't work!!! > > This may very well be true as OpenSSL doesn't support [m]any 16-bit platforms > out of the box AFAIK. I've had to tweak a few things here and there every time I > did such a thing. > > > If someone have a previous version that can compile I am also very > > interested, I only need to include what the rsa util (from the command > > line interface) needs, thus not the whole crypto lib. > > Terribly sorry, but I have done that for a client of ours and I don't have their > permission to post the results. :-( > > Since you are interested in the rsa util stuff only, I'd suggest stripping > everything off on a 'proper' 32-bit platform to make sure the 16-bit headaches > don't get your hide from day 1. When your properly stripped version works on > UNIX or Win32 (seems to me you can ditch the whole /ssl/ dir plus mucho dirs > from /crypto/ or do you want all features offered by rsa.c?), ONLY THEN jump > into the 16-bit arena and fight it out with Borland C++ in 16-bit mode. > > As mentioned above, make sure your 8.3 filenamed, C identifier-32-character-only > processed sources still work on the Win32 platform (or Linux if you started > there), before migrating the code to 16-bit. > > > > currently doing a program to change the sourcecode to reduce var names > > to a max of 32 chars, I have a feeling though that my struggles will > > not stop at that. > > Yup ;-) Next stop: "Gosh, my int is 32 bit. Ah mean... 16 bit..." Fortunately, > the RSA stuff is all nicely based on BIGNUM stuff, which 'knows' about 16-bit > integer compilers. Check out the SIXTEEN_BIT #define in opensslconf.h; that > should get you going for a while. I haven't used it lately though, YMMV. In the > old days, it worked pretty well. Had to tweak only a few 'int' to 'long' then. > > Since it sounds like you're on an Intel x86 platform, make sure you compile your > goods in 'large' or 'huge' model as you may have extra headaches otherwise, > thanks to linkers complaining about too large data segments. > > Note: you don't need to _reduce_ C identifiers to 32 chars IIRC, but *only* need > to make sure they are _uniquely_ _identifyable_ within their first 32 chars, > i.e. the compilers chops off any surplus characters while compiling, so you > don't need to patch each and every identifier, just the ones that may clash with > each other in their first 32 characters. See symhacks.h for a list of the ones > that might do this. (VMS had a similar issue IIRC) > > You might also find you'll need to patch rand_win.c to suit your system; it's > used for collecting much needed entropy and may need to have some Win32 Windows > API removed (and possibly substituted by other items that add a bit of noise to > the random pool). > > > chars, filenames has to follow the 8.3 length rule and things has to > > be declared in the right order. > > 'right order'? I don;t recall any trouble with that, as ye old faithful C > compiler and any hip modern one still all share the same faith about the 'right > order' AFAICS. Or do you mean you have to mix with different languages? (e.g. > __cdecl vs _stdcall, i.e. __pascal style function argument passing?) > > > > And then... why would you do all this if you only need RSA? (There are still RSA > sources out there for 16-bit AFAIK) Or do you (a) have faith in OpenSSL (amen, > brother!) or (b) also want the PEM/ASN1/etc.etc. goodies from /crypto/ too? > > > > > > > Best regards, > > Gerrit E.G. Hobbelt
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
