Table Of Contents
|1.||17�Jan�2004�-�23�Jan�2004||(4 posts)||News: Wine-20040121, TransGaming Stuff, C4|
|2.||20�Jan�2004�-�22�Jan�2004||(16 posts)||CodeWeavers CrossOver Compatibility Center|
|3.||4�Jan�2004�-�19�Jan�2004||(6 posts)||Winecfg Additions|
|4.||21�Jan�2004||(4 posts)||Graph of CVS Commit History|
|5.||16�Jan�2004�-�17�Jan�2004||(5 posts)||MSHTML Changes|
|6.||21�Jan�2004�-�22�Jan�2004||(2 posts)||Broken Apps: IE Setup and Lotus Notes?|
|7.||16�Jan�2004||(1 post)||Running MS Office|
|8.||18�Jan�2004||(3 posts)||INSENG.DLL Stubs|
This is the 206th issue of the Wine Weekly News publication. Its main goal is to drink the koolaid. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org (http://www.winehq.org)
Mailing List Stats For This Week
We looked at 261 posts in 950K.
There were 68 different contributors. 41 posted more than once. 34 posted last week too.
The top posters of the week were:
1. News: Wine-20040121, TransGaming Stuff, C4
17�Jan�2004�-�23�Jan�2004 (4 posts) Archive Link: "News"
People: Alexandre Julliard,�CodeWeavers,�TransGaming,�Gabe Newell,�LinuxWorld,�,�codeweavers,�Microsoft,�Jeremy White,�Xandros,�News,�Peter Hunnisett
Welcome to another action packed issue of the Wine Weekly News - a beer-soaked newsletter infatuated with Paris Hilton spam. The headlining news this week is a new Wine vintage:
WHAT'S NEW with Wine-20040121: (see ChangeLog (http://cvs.winehq.org/cvsweb/wine/ChangeLog?rev=1.79&content-type=text/x-cvsweb-markup) for details)
Now.. go download it (http://sourceforge.net/project/showfiles.php?group_id=6241) and submit patches for all of the bugs you find.
CodeWeavers announced a new initiative this week to help software vendors port applications to Linux. Jeremy White also started a thread about part of this on wine-devel, I'll cover that next (which will clear up some details concerning it.) CodeWeaver's announced the CodeWeavers Desktop Linux Certification Program (http://www.codeweavers.com/site/about/general/press/?id=20040120) on Tuesday. From the press release:
CodeWeavers' Desktop Linux Certification Program includes several key elements:
Hey Microsoft - here's your opportunity to get some software Linux certified.
TransGaming put out a slew of little news blurbs along with their January development report. If you're wearing (http://www.transgaming.com/showthread.php?news=104) a TG t-shirt at LinuxWorld you might end up with a gift certificate. So both of you guys with t-shirts be sure to show up. TG is also looking for WineX beta testers (http://www.transgaming.com/showthread.php?news=103) . Steam fans might be particularly interested in that because support may be appearing in the upcoming WineX 3.3 (http://www.transgaming.com/showthread.php?news=105) . Finally, TG's newsletter gave a pointer to an interview with Peter Hunnisett (http://www.usalug.com/reviews.php?op=showcontent&id=6) by USALUG. I thought was pretty lame. (*whine* why do we have to pay for software *whine*)
In TransGaming development news, Point2Play 1.2 (http://www.transgaming.com/showthread.php?news=106) came out this week. Multiuser capabilities now allow WineX packages to be shared rather using a separate install for each. German and Portugese translations are also available and users are invited to translate the package into other languages. The January Development Status and Voting Report (http://www.transgaming.com/showthread.php?news=102) contains info on what they've been up to behind the scenes:
Following the December development report we received an email from Jaroslav Kysela of SUSE, who kindly provided us with some technical insight on how to overcome the limitations we perceived in ALSA. With this information we now believe that we should be able to provide hardware mixing in a straightforward manner while also using memory mapping for data transfer. These two features combined have the possibility of providing some major improvements to speed with a complete rewrite of the winealsa sound driver.
Since the last report we have also been active with our Pixel Shader investigations. We now have a working pass-through implementation that allows us to pass pre-translated fragment programs into OpenGL. The next step here is for us to translate the D3D pixel shaders into OpenGL fragment programs, trying to support as many of the shader language versions as possible on the existing OpenGL fragment program specification. We will be working on refining this for inclusion into WineX as well as working proactively to address some of the limitations of the proposed OpenGL 2.0 specs for fragment programs, making it a better translation target for D3D shaders version 2.0 and up.
They also want you to stop voting for Half-Life 2 until they can get a legal preview copy or the legal release. If you hadn't heard, the source code to the unreleased HL-2 was stolen (http://news.com.com/2100-7349_3-5087698.html) last September. Valve's managing director, Gabe Newell, thought (http://www.fragland.net/index.php?page=newsitem&nid=6041) the leak was due to a security problem in Outlook, " At some point, keystroke recorders got installed on several machines at Valve. Our speculation is that these were done via a buffer overflow in Outlook's preview pane." HL-2 was in the news again this week as the FBI conducted raids (http://games.slashdot.org/article.pl?sid=04/01/19/1752221&mode=thread&tid=126&tid=127&tid=186&tid=204&tid=95) on people suspected of stealing it.
More Xandros reviews are appearing. The review from Distrowatch (http://www.distrowatch.com/dwres.php?resource=review-xandros) briefly mentions CrossOver. ExtremeTech's review (http://www.extremetech.com/article2/0,3973,1448588,00.asp) goes into a lot more detail about CrossOver integration.
Finally, just as this was about to get published, I found an interview with CodeWeavers' Jeremy White (http://searchenterpriselinux.techtarget.com/qna/0,289202,sid39_gci944905,00.html) on SearchEnterpriseLinux.com.
2. CodeWeavers CrossOver Compatibility Center
20�Jan�2004�-�22�Jan�2004 (16 posts) Archive Link: "RFC on our new initiative"
Topics: Project Management
People: Jeremy White,�Mike Hearn,�Greg Turner,�CodeWeavers,�,�codeweavers
The news blurb above alluded to the CodeWeavers CrossOver Compatibility Center (http://www.codeweavers.com/site/compatibility/) , or C4. Jeremy White provided more details in an email to wine-devel:
We've just launched a major new initiative, the CodeWeavers CrossOver Compatibility Center.
You can check it out at
I wanted to announce it here to give folks a sense of what we're up to, and to apologize a bit in advance for stepping on the toes of folks that have been doing good work within the appdb.
However, the #1 problem we have had over the past year or so is how to handle all the many, many requests we get for applications not on our 'supported' list.
We've basically ended up sending people away, which has been pretty unsatisfying. Further, we haven't had any good way of determining what our priorities should be; we follow major paying clients, but beyond that, we mostly just follow our gut hunches in establishing priorities.
We hope to end that; this new center lets our customers vote for apps, and lets non customers make pledges. We can hopefully follow those pledges to get apps running (and we'd probably be open to having wine hackers committing to support apps in exchange for a piece of the pledges, but we haven't gotten there yet).
We've also, we hope, set the stage for a major new Wine related initiative - we hope to encourage lots of ISVs to certify their apps against Wine.
The rationale for this is pretty simple - apps won't run on Wine as well as they do on Windows until developers start testing against Wine. They've got to start somewhere - we're trying to give them that beginning.
We're obviously also hoping that this will help us to continue funding the work we've been able to do on Wine so far. As much of a struggle as it's been at times, we really feel lucky that we've been able to do so much. We hope that these initiatives will give us an extra little boost so we can help push Wine over the hump.
I sincerely believe that the day when we can honestly tell people "It will most likely work nicely on Wine" is not long off.
I also believe in the tooth fairy and Santa Claus, so make what you will of that <grin>.
At any rate, this is a brand new initiative for us; call it an 0.1.7 release. We're very open to comments and thoughts and suggestions, so I would greatly appreciate any public or private comments you have to make.
Wow.. talk about blurring some lines between commercial and non-commercial development. Users of the LGPL'ed Wine benefit only indirectly from this. CodeWeavers is a very benevolent member of the Wine community and it's safe to assume work done for their CrossOver line of products will eventually make it into Wine. Mike Hearn expressed concern along those lines:
I'm also a tiny bit concerned that the site seems to blur its focus a bit - it seems to be positioned as a replacement for the appdb, despite the fact that it's CrossOver specific: I think there's enough forkage between CX Office and Wine now to make them basically separate products.
For instance, on the front page, there is this paragraph:
This piece of text seems to use the names Wine and CrossOver interchangably, when they are clearly different.
As for the database itself, well, it seems that it duplicates a lot of stuff needlessly - take "Alone in the dark". In the appdb there is only one comment which is basically "Works great!", but there is no indication the game works in C4. There's also no indication in either database whether it actually works as of Jan 2004.
Worst of all, there's no way to verify this except for a Wine developer buying a copy of the game, checking it, and possibly fixing regressions. So I'm not sure that an appdb type thing is even a good idea - a dedicated application maintainer who brings the app up to scratch, periodically checks it still works and so on is easily more valuable than a hundred appdb entries saying "This app doesn't work June 1998" or whatever, even if you have far fewer of them.
The idea of advocates is a turn off for me. It sounds like a revival of the old application owners idea, except that (again) it's crossover specific. It also feels a bit misleading. I think we'd all agree that the following phrases:
... makes it sound like all you have to do to get foo-app working is download CXO nightlies and report back the results. We already have this in effect, it's called bugzilla, and we all know that getting tester feedback of sufficiently high quality to fix the bug is while not rare, not the expected outcome. Bugzilla and the appdb are littered with comments like, "The app starts but then I get a message about flat scrollbars which crashes wine".
Is the CrossOver team going to trawl through C4 looking for feedback from the Advocates fixing bugs given (at best) a stack trace and a logfile? It'd be nice but the incoming workload scales much better than the workforce does.
Possibly there's something I'm missing here, like CXTest. Something like that sounds invaluable for tracking regressions if it works well, and maybe it's the secret sauce. I'm not sure.
Finally (sorry guys! :) the FAQ lists the first advantage of C4 over the appdb as the fact that it's maintained, but the cynic in me can't help noting that if you're capable of maintaining C4 you'd be capable of doing the same for the appdb ;)
I know I'm giving you a hard time here, and while I really appreciate all you're doing I thought I'd better air my concerns.
Jeremy wrote back to address the issues Mike brought up:
I also have a crazy dream of buying thousands of MS Windows titles, locking Aric in room until they all install, and then nailing them all to the floor with CXTest. I think this is conceivable (except for the part where Aric goes crazy and bludgeons his way out of the room with his laptop <grin>). And, I would argue, if were to truly make an effort to get every application to install and come to the main menu, we could make my prediction come true. I just need a bit more money, and a secure enough room to hold Aric...
We're genuinely motivated primarily by a desire to see Wine fly. However, we are also required by our spouses and physical law to make enough money to eat.
C4 is intended as a community primarily surrounding CrossOver, although the carry over to Wine is obvious. Essentially, the C4 community becomes another benefit of buying Wine from us, rather than simply downloading it for free.
So, yes, it is intentional that C4 is focused around CrossOver.
But I am concerned about the impact this will have on the appdb. I didn't really want to step on the toes of anyone that has been working on the appdb; that's a hard and largely thankless job. But I still believe in the original vision of the appdb (that's why I paid Jer to build it); I just think its going to work better in a context where it has a chance to pay for itself, so I can afford to pay someone the dirty job of keeping it up to date.
Further, we do think that CXTest is going to add a meaningful and useful component to this. If nothing else, I'm hoping that CXTest will let us 'lock' applications in so that once they start working right, we can prevent them from regressing.
Again, the primary purpose of C4 is to give our customers somewhere meaningful to go when they want to work on an app that is outside of our 'supported' list. People can either put their money or their time where their mouth is, or stop bugging me <grin>.
As an aside, we have started working on a new policy of patch submission. We had always held an internal tree, worked against it, and then submitted a delta after a release. The merging started to become unmanageable, and so we've switched policy so that (ostensibly) all of our guys submit patches here first, and then we merge into CrossOver frequently. Once we get going with C4 and CXTest, this should have the nice side effect that Wine will get a regression testing tool and a company to run said regression tests every night. (Our goal is to be able to pinpoint the exact patch that breaks half-life <grin>).
We don't get paid to maintain the appdb, and if we did maintain it, we'd encourage people to *not* buy CrossOver, imho. We do get paid by people who buy CrossOver, and we've hopefully given them a reason to be glad that they chose to give us their dollars.
I appreciate the concerns; I really appreciate that you looked it over carefully and took the time to raise your concerns.
We're genuinely trying to figure out the best way forward, and we want to do what's best for everyone involved.
As a result, we're very open to suggested changes.
Greg Turner wondered how well the forums worked:
Looks great to me; although there are not any discussions yet (or are there?) in the "forums" area to demonstrate the quality of the forum interface, if it's something along the lines of phpBB, then it's perfect.
In my mind, the appdb is great, but better, threaded, discussion areas were needed for people to really get serious about it.
As for wine vs Crossover -- I presume that "plain old wine" users are welcome to participate? If so, then there really isn't a problem.
Jeremy felt that was okay, " Our main emphasis is going to be on CrossOver, because we can quantify and control it. But we'll absolutely welcome general Wine conversations and users (but the version drop down boxes will all be CrossOver versions, for example). "
CodeWeavers has managed to build a nice community around its products. With a little luck that community will be sufficiently large enough to help maintain C4. It's something Wine community has never really been able to do with its AppDB (http://appdb.winehq.org) . That's not to say the AppDB isn't useful - if you dig deep enough you may find the solution to your problems. However, taking it to the next step and allowing people to vote where commercial development $$$ will be spent seems like a wise move.
3. Winecfg Additions
4�Jan�2004�-�19�Jan�2004 (6 posts) Archive Link: "[winecfg] - audio tab w/autodetection, misc"
People: Robert van Herk,�Chris Morgan,�Mike Hearn,�
Winecfg recently saw some more additions. If you've been following the story so far then you'll know that's the application that will someday be used to configure Wine. Right now options are set in the .wine/config file but a graphical interface is preferred. Wine loads the config file entries into a read-only branch of the registry upon startup. When Winecfg is complete the config file can be ditched and all options stored directly in the registry. Some of the more obscure options will require regedit to edit them. Wine really needs a developer to tackle this. Robert van Herk and Chris Morgan have recently made additions so it's possible things are on an upswing. What Robert did was, " Added a tabsheet that allows the user to change the dll overrides, both globally and per app."
Chris' addition involved adding some audio configuration: " This patch adds an "Audio" tab to configure the audio driver that wine should be using. I also put together an autodetection routine that isn't complete and is almost certainly not portable. If you see anything that can be improved or that needs to be conditional upon platform feel free to send me some mail. Autodetection also needs support for Nas and audioIo. Also added support for double clicking in the "Drives" tab on a given drive and linked this to opening the edit dialog. "
Mike Hearn wondered if maybe the detection code needed to be put in Wine rather than a separate program. Chris wasn't sure, " If other people think it makes sense then yes, I think we should probably move the autodetection code to run at wine startup. The code thus far is very much non-portable so while it should work under linux I'm not sure about other os's. I've considered also trying to dynamically load the sound libraries and use their library calls to detect the sound libraries. Any improvments or suggestions are more than welcome. The autodetection works well for me though so I'd imagine it would work for most linux end-users. "
Alexandre committed the changes as is.
4. Graph of CVS Commit History
21�Jan�2004 (4 posts) Archive Link: "Re: RFC on our new initiative"
Topics: Project Management
People: Rein Klazes,�Mike Hearn,�,�Rein Klaze
During the course of a discussion Mike Hearn wondered what a graph of CVS commits would look like. Rein Klazes put together the data:
A quick awk script on my cvs in box produced monthly number of cvs commits. That includes the commits to winehq.
Output attached, a graph produced with gnumeric is on
Mike wondered why the end of 1998 seemed so productive. Rein felt two factors might have had a hand it: in October CVS mistakenly reported the same commit more than once, however at time Corel was actively working on Wine and there geniunely were a lot of commits.
Note - this graph does not reflect the size of the Wine source code. It's only the commits. Anyone want to produce a graph of how much has been added? I think it would be interesting to see the trend.
5. MSHTML Changes
16�Jan�2004�-�17�Jan�2004 (5 posts) Archive Link: "Re: Try using the Mozilla Active X control in MSHTML"
People: Mike McCormack,�Dimitrie Paun,�,�Microsoft
We've sort of discussed this before.. the elusive IWebBrowser control. It's used by AOL, Quicken, Outlook, and lots of other apps. For more info, see the discussion last year in issues #141 (http://www.winehq.org/?issue=141#Web%20Browser%20Integration%20Needed) , #147 (http://www.winehq.org/?issue=147#IWebBrowser%20Status) , and #153 (http://www.winehq.org/?issue=153#IWebBrowser%20Status%20/%20More%20Ideas) . Along similar lines, Mike McCormack posted a patch to begin using the Mozilla ActiveX control in place of Microsoft's parsing engine (MSHTML):
Since some people have been complaining that MSHTML is a useless distraction in it's current form (there's some element of truth in that), here's a small patch to redirect calls to Mozilla's Active X control. You need to add a "mshtml"="builtin,native" override in the config file and download and install the control before this patch can try to use it:
This patch hasn't been tested too much... but it's better than the current implementation of MSHTML :)
Dimi wanted to know how well it worked:
Very nice Mike! I guess this requires a Win32 build of Mozilla, no? Anyway, if the patch goes in, it would be nice if our good packagers can come up with a binary package (say, wine-mozilla?) that just installs alongside with the wine package and provides this capability.
BTW Mike, did you try to see if HTML Helps works with the Mozilla control? We had a task to add CHM support to WinHelp, but first we needed an implementation for IWebBrowser. People were arguing that Mozilla is not that IE compatible, and that using it for the IWebBrowser component will not work for a lot of cases, but I still think this is the way forward. Even if we chose in the future to have another IWebBrowser implementation based on khtml, this will nicely fill in the gap in the meanwhile, without any maintenance problems for us.
Mike said an initial try didn't work:
I didn't really have much time to do testing with it... tried to use it in place of IE6 and IE4's mshtml, but it didn't work.
Using Mozilla to implement IWebBrowser seems to be the Right Way for me, as the Mozilla project is already trying to do that themselves... it's a common goal that we can work together on!
It would be pretty cool if we could compile Mozilla as a winelib app, or figure out how to do get debugging info out of the control so we could see what needs to be fixed for it to work.
I'm pretty interested to work on this too, but unfortunately there's other "real work" that I need to get done at the moment.
6. Broken Apps: IE Setup and Lotus Notes?
21�Jan�2004�-�22�Jan�2004 (2 posts) Archive Link: "Lotus Notes broken in recent CVS"
People: Mike Hearn,�Kevin Koltzau,�Paul Streitman,�,�News
Normally I don't report on broken apps, I rarely even report on working apps. This week two different reports came in for some widely used programs not working. First, Mike Hearn sent a message to the list about Internet Explorer issues:
A large UXTHEME update was committed in the last few days. It appears this causes the IE installer to crash. I'm currently bogged down with exams, it'll go on my list of regressions to track down and nail, but may take a few days or weeks, depending on how things go here. For now I'd suggest using 20031212, CVS is highly unstable and iesetup regresses all the time at the moment.
I've copied this one to wine-devel as well so Kevin can see the crash.
The work Mike refers to are some large patches from Kevin Koltzau that implement Windows' theming (i.e. uxtheme.dll). We covered some discussion of uxtheme.dll back in issue# 191 (http://www.winehq.org/?issue=191#Theming%20&%20UXTheme.DLL) . Kevin followed through with that work and now we're beginning to see the foundation of it appear. As Kevin stated in one of the patches, " This implements just enough at the moment to possibly trick some applications into thinking theming is actually available, which could break them (mostly display issues if the app ignores errors on theme drawing functions) This will only be an issue if you have a theme installed and selected in your registry "
The other app having problems is Lotus Notes. Paul Streitman reported, " For the last couple days, Lotus Notes (5.0.11) has been broken under CVS Wine. Since Wine was released as a snapshot, I thought that I had better speak up because it is still broken and no one else seems to have noticed a problem with whatever recently changed.. "
Both of these apps see widespread use under Wine and there will likely be fixes to them soon. If you have a problem with Wine-20040121 you may want to consider building Wine from the latest CVS (http://www.winehq.org/site/cvs) . It's not that hard to do and may fix your problems.
7. Running MS Office
16�Jan�2004 (1 post) Archive Link: "[Fwd: Bug#224498: A recipe of potential use to MS Office 97 aspiring users on Debian]"
People: Emmanuel Charpentier,�,�Microsoft
There's lots of info out there on running MS Office with Wine, including Frank's Corner (http://frankscorner.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=20&page=1) , but I thought it might be nice to include some instructions that appeared on wine-devel this week:
First, a big "Thank you" to Ove : maintaining a Debian package is work, and maintaining a beast such as Wine is *hard* work. I feel very grateful to Debian maintainers, and to Ove.
I have read the bug report about MS Office and the consecutive somewhat heated argument. While I won't delve in the "necessities" of using MS programs, I agree that there is not yet a free tool able to reach into .mdb databases sent by people you can't demand another format. (Yes, I'm aware of the .mdb tools. They crash on me any time I try to use them on a French .mdb ...). Ant that might be justification enough to try to get Wine working with that piece of s...oftware.
The following recipe *might* help people not yet able to get rid of MS Office. Start by getting the latest (20031212) version of wine (that's in unstable for you, Debian users ...). This version seems to be a *vast* improvement over whatever I tried before (last time was summer '03, IIRC).
You will need a working Windows 98 installation (for which, of course, you have a valid license...). But you'll have to start with a fresh no-windows installation. The simplest way I found is to rename any previous .wine/config file and .wine/fake-windows directory, then to call winsetup and to ask for the creation of a new config file without Windows installation.
Starting from here, install from the MS cdrom : wine /cdrom/install.exe. This installation will copy a lot of files, then FAIL. That's not a problem.
You'll then grab the following files from your working Windows installation:
IIRC, all of this, except vba332.dll come from the \Windows\System directory of your native Win98 installation and go to .wine/fake_windows/Windows/System directory. In the .wine/config file, mark these libraries as "native,builtin" in the [DLLOverrides] section.
Restart the installation of MS Office from the CD. This time, the installation should work (and be much faster than the first time around, since almost all file already exist). It will complaint that it cannot DDE-connect to the desktop (in order to create the shortcuts), but that's harmless : just hit "Ignore".
The first launch of the applications may be painful : at first run, MS Office apps try to launch a "helpful" dialog box "presenting" the application, which have trouble communicating with the main program. I found that minimizing and restoring the main window may help. Don't ask me why.
As far as my limited test can tell, Winword and Powerpoint work fine. With the relevant fonts in xfs and a correct CUPS setup, printing is automatic and gives very good results.
MS Access still gives me guff : I have Cyrillic characters in place of Western accented characters, form creation dialog boxes have serious quirks (e. g. the "Properties" dialog box fights for focus with the "Save as" dialog box in Design mode), I had a crash trying to display an "outer join" view, etc ... But that is infinitely better that no MS Access at all ... I have now some hope of solving some of these hurdles.
The SR1 and SR2 "service packs" can be installed with no problems.
Hoping this helps,
PS : Ove, if you think this might be of interest elsewhere, and does not step too rudely on the (very) sensitive toes of DFSG and Social Contract, please feel free to forward to any relevant place, cut and paste or paraphrase at will ...
PPS : Mandatory disclaimer : I found this by trial and error. I might be wrong. But that's my problem. Now, I won't accept *ANY* responsibility for the (mis-)use you may make of this information, either technical or legal. In other words, you're on your own : if this blows your system, drowns your basement, launches against you a thousand of ships full of angered Microsoft lawyers, shaves your cat or rapes your grandma (or vice-versa), that's *YOUR* problem, buddy, not mine.
(Normally I wouldn't include the extraneous stuff in an email, but Emmanuel's was pretty amusing.)
8. INSENG.DLL Stubs
18�Jan�2004 (3 posts) Archive Link: "INSENG, IActiveSetup and ICifFile interfaces ..."
Topics: Creating Stubs
People: Mike McCormack,�Mike Hearn,�
Mike McCormack investigated an obscure DLL:
This is a stub implemenation of the undocumented IActiveSetup from Internet Explorer's INSENG.DLL. I'm not sure that any other software except for Internet Explorer uses INSENG, however incase anybody is ever interested in it, I'm posting it here.
To build this dll in wine place the following 3 files in dlls/inseng, remove the #MKDLL_SKIP line from Makefile.in, add dlls/inseng/Makefile to configure.ac and run make_dlls.
Hopefully this will be of use to somebody someday...
Mike Hearn asked the obvious question, "If IE ships it, and uses it internally, why do we need to reimplement it?" Mike admitted it was more of a mistake than anything else:
Well, I don't think we need to implement it, unless we find some other program that uses it but doesn't install IE first.
I started writing this because IE didn't seem to install INSENG.DLL when using Version=win2k, but later found that it was a wierd dll override problem.
Rather than just throw away the work from that misadventure, I decided to post it here incase somebody did need it or was curious :)
Sharon And Joy