Curious Deployment Ponderings

Jerry Haltom jhaltom at feedbackplusinc.com
Mon May 10 12:27:19 CDT 2004


This could be possible right now, I've just got it floating around in my
head and wanted to write it down someplace permanent so I don't forget.

Right now there isn't really any concrete methodology for installing
Wine is there? By this I mean something similar to how Perl, Python,
Java, Mono, and all other runtime environments on Unix behave (Wine is a
runtime environment eh!). A standard common directory (/usr/lib/win32)
for Win32 .DLLs. Smarter directory diversion: "pretending C:\Program
Files" is /usr/lib/win32-software or something".

All of this is just floating around in my head, given some things i've
noticed that I myself tend to do when I use wine... I keep my own C:
drive in ~. There is no sharing of .DLL resources between users, and no
potential for it. There is also no ideal way for a vendor to package
Windows applications up into a proper RPM or DEB file, which installs
the .dlls in the right place, and the program in another, and depends on
the right infrastructure. It's pretty disorganized right now.

Has anybody given relaying out Wine as I described any thought. I know
Windows programs aren't the friendlyest for such a thing... Some save
settings in Program Files, so putting it in /usr would be bad...

But then again, lots of new Windows programs do behave good, putting
settings in C:\Documents and Settings, and the HKCU key of the registry.

Food for thought anyways.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20040510/ac3cd747/attachment.pgp


More information about the wine-devel mailing list