TWIN - a Free Windows emulator under VMS (note also [vmslt97b.moreau]wxw*.* which is a set of libraries which allow one to develop code that runs under VMS, Unix, Windows, etc. all the same.) This area contains the below-mentioned TWIN port to VMS and also the later code from the web site. Article 174179 of comp.os.vms: Like most of you I was hoping when the Affinity program came out that it would result in Win32 libraries shipping with OpenVMS. Well, it did, but *using* the Wind/U libraries was prohibitively expensive for us, with a $10000/seat charge for the developer's tools, and per user licenses on the result. I'm not faulting Bristol Technologies for this - those folks have to eat, but with all of the hoopla Digital made it sure sounded like they were building these goodies into OpenVMS, not just shipping somebody else's libraries and blowing smoke. Wind/U was never the only game in town on Unix systems, and one of the other players was Willows. The Willows product ran on all the same Unixes, and also Mac, but not on OpenVMS. Willows seems to have gone into the great beyond, or at least, onto other projects, but amazingly enough, their TWIN product, rather than being sold to somebody else, was GPL'd and put into the public domain. In a nutshell, this means that Win16 and Win32 libraries have more or less fallen into our laps - if we can get them to run on OpenVMS. For a more thorough discussion of what this code does direct your browsers to http://www.willows.com/ I have taken a first rough step at a port of the TWIN code, to the extent that I've managed to make most of the pieces compile cleanly on OpenVMS 6.2/Alpha with DECC 5.5, for the 32 bit form of the libraries. (I figured that the 32 bit form would be the most useful since most new software is written that way.) I started with the 3.0.10 release from the web site listed above, and you can have it with my changes for your very own via: http://seqaxp.bio.caltech.edu:8000/pub/SOFTWARE/TWIN_3_0_10_VMS_001.ZIP (That is, 3.0.10, VMS version 1) There is *plenty* of work left to do on this, so if any of you want to jump in, here's a short list: 1. The makefile's are very difficult to understand and the documentation gives whole new meaning to the word "meager". We need to know for nonLinux, non386 processor systems exactly which pieces go into which libraries. 2. The resource compiler pieces [.bin.rc] all compile, but there are missing symbols at the link stage. Also, rc is critically dependent on using FLEX, which raises all sorts of licensing issues for any commercial products that might eventually run on top of this, and it would be good if the rclex.l file could be edited so it would work with POSIX lex. 3. The socket stuff is completely out of my league. Network gurus please attack [.PAL.X11]DRVWINSOCK.C 4. [.WIN]COMM.C implements serial line control with a bunch of unix specific code. If you breathe QIOs and are familiar with Unix this code is for you. 5. The method they use to load DLLs is bizarre, even on Unix. There is a dlopen, but no dlsym. I've asked Rob Farnum about this, and this is the clearest explanation I've had, but it is still largely greek to me, if you understand it, then please have a go at it: "Under windows, a dynamically loaded dll, has an entry point, (LibMain(), or DllEntryPoint() that takes specific arguments, and is called when the library is LoadLibrary()'d. Most dll's will take this information and save it away for later private usage. Because access to symbols and functions are controlled through windows API's, and defined by the use of a module definition table, AND to be portable, we have our resource compiler build a table specific to the dll, that allows us to know what legitimately may be accessed via the windows api's. It does NOT have anything to do with parameter definitions, etc, and any caller MUST know how to call the api's apriori. The whole purpose of COM/DCOM is to fix this limitation in a uniform way. So the whole point is that we need to call the library entry point when a dll is dynamically loaded, (and unloaded), but we don't necessarily (within the library) know what that is. We arrange to have a special initialization function called first, that returns a table, that contains the address of the entry point function that the dll expects us to call a specific way. > I don't understand the purpose of all the callbacks. What > exactly do the tables hold? I'm guessing the number and > types of arguments, offsets into the DLL? Anything else? > > "callback to the LibMain()" is particularly alien - there > is no such beast on OpenVMS. The above should help, but it does go deeper. The table returned by the initfunction also has a pointer to the dll's resource table. When anyone calls one of the functions to access a dll's resources, (by passing in the dll hInstance), we can look up and access the dll's resources through that table. The callback is to support the semantics of a windows dll, which needs access to its own hInstance, to access its own resources. The dll expects its LibMain entry point to be called, so it can get its own hInstance. > Why do you need to call them by ordinal #? I can >implement this easily enough by mapping numbers to names, >but what's wrong with just names? That is the definition of the windows api, specifically, when we run the code on win16 and win32 binaries, (ie. interpret them), we run into this construction all the time. It is an artifact of win16 where rather than search tables by name for entry points, microsoft used ordinals to simple index into the table. Ie. I don't have an option when running the emulator, and if we want to implement according to the defined api." 6. There are several issues that I've skirted in getting things to compile have a read through the AAA_VMS_PORT_NOTES.TXT file, and look for "NOT FIXED" 7. Rats! I see that in the last few days the willows site has gone up to 3.0.13. So add merging those changes in to the task list below. Obviously I don't know how much work it will be to get all of this to fly, but since it apparently runs on Linux and several other Unixes, the odds are good that it won't be horrifically difficult. Besides, once this beast is available we can turn our attention to the intel/Alpha WNT code translator problem. FX!32 is out of the question, but something like VEST may not be, especially given the availability of the TWIN32 libraries and intel binary to C decompilers. Regards, David Mathog mathog@seqaxp.bio.caltech.edu Manager, sequence analysis facility, biology division, Caltech ************************************************************************** *Affordable VMS? See: http://seqaxp.bio.caltech.edu:8000/www/pcvms.html * **************************************************************************