What happened to the Fedora packages? They have not been updated since
0.9.2!!!! Right now it is at 0.9.10!!! Nearly every other Linux distro
supported has the up to date packages!!! And why does the Red Hat packages
site not go to the SourceForge site as it does for SUSE packages and the
others?? I have not really had the guts to ask until now, because I thought
that maybe there was a slump, but now, its getting annoying!! And Fedora
just released Fedora Core 5 yesterday!!! Please tell me new …
[View More]packages will be
ready soon!!! Compiling WINE always crashes my computer, so I prefer to use
the RPMs...
[View Less]
Hi.
>From which configuration does the "ERROR_INVALID_NAME" came from,
when calling GetDefaultPrinter(NULL, &size) and no Printer is installed?
This Test is Present in the current "dlls/winspool/tests/info.c".
MSDN told us, that we receive an "ERROR_FILE_NOT_FOUND", if no Printer
is installed:
http://msdn.microsoft.com/library/en-us/gdi/prntspol_0hma.asp
I get the "ERROR_FILE_NOT_FOUND" on win98se, winme, w2k and win2003 in
this Situation.
--
By By ...
... Detlef
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I think after the 10 or more patches to the Wintab dll that I submitted
last month, I should say something about it's status...
And of course thank Alexandre for applying those patches.
P.S. I won't be available from the 15th for about a week or so.
So, if you have any questions, I'm afraid you might have to be patient.
Hope this is of interest to someone
-Rob.
******Applications: Current status***********
***In Painter 5
*Cursor pressure …
[View More]works. (Therefore is usable by most)
*Cursor orientation is a little odd: The orientation maths needs to be
re-done.
*No eraser. Haven't yet cracked what enables the eraser.
*Doesn't work in desktop mode: Need to map to desktop coordinates.
*Repeats windows bugs where cursor looses pressure/orientation info
almost bug for bug (Is this a feature? ;-)
*Cannot detect pressure/orientation int the "Brush Tracking" window: The
tablet context is attached to the main window, so no events get to the
popup, even if they overlap.
This is not how windows wintab functions.
***In Photoshop 6.
*Can only get tablet data in desktop mode: This is because the tablet
context is attached to the desktop. Which generates/receives no wine
events outside desktop mode.
* Eraser and pen pressure working. *But* to get them working, you must
have 3 XInput devices listed in your XF86Config file, They need to be
the last entries in the "ServerLayout" section and the following order:
eraser, tablet mouse. This is a far from ideal way of specifying the
devices Wintab should use :-/
I'll document this if someone can point me to a good place to put the docs.
*******To Do*************
1. Look at X11 errors. There appear to be some errors that deny some
users the
ability to access Wintab enabled apps. (I think I know how to fix this)
2. Improve orientation data. Orientation comes in as X-Y coords
(Implicit Z), and has to leave as spherical coords. This calculation
needs to be re-done.
3. When tablet context is on top, let it read XInput events from all the
app's top-level windows. (This simulates the fact that the context is
usually designed to cover the whole screen)
4. When tablet context is attached to desktop, read XInput events from
all the app's top-level windows.
5. Tests
~ --My current philosophy on tests is...
~ Use Photoshop & Painter, any formal tests
~ can be written if anyone else gets involved in patching Wintab, to
avoid regressions, and conflict.
**********Long term to do (Anyone interested?):*********
There's a lot of work that could be done here, but what gets done
and who does it probably depends upon whether anyone finds an app that
needs these features. I'd love to implement these, but realistically, I
don't
foresee doing this unless someone hires me to do so ;)
1. Improve configuration of wintab.
Wintab could probably do with some information entered into the
config file, to avoid the user having to
hack their Xfree86cfg file.
2. Handle Z-Order of context properly.
This entails
*sharing Z-Order between apps.
*Working out exactly what role windows have in
determining tablet context z-orders.
*Allow tablet contexts that don't cover the whole
screen/tablet.
*Handle inter-application clipping of tablet contexts
*Allow all application's windows to receive tablet events when tablet
context is on top
3. Implement non-system tablet contexts (Where system cursor not moved
by pen or mouse)
4. Unicodify
5. Implement various wintab extensions.
6. Implement wintab manager functions.
7. Tests.
*********Unknowns*********
1. How are wintab contexts are raised lowered?
Contexts have their own z-order independent of windows, and their own
viewport concept, based upon the tablet's coordinate system, not that of
the OS.
It appears that entering, or clicking on the window the tablet context
is attached to will raise/lower the context.
But I haven't done much testing on this.
In particular, what happens if more than one app request their tablet
context is attached to the desktop?
2. How Painter detects the eraser.
Have 3 possibilities
i. Windows can detect an eraser, and sends specific messages.
(I'm sure I've seen this, but can't work out where!)
ii. Only works if tablet and cursors are named correctly.
(Probably linked to wacom tablets only).
iii. I've missed something
3. Requirements of other applications
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCC8zI2vfwxdLxwWYRAsisAJ4q2gAYTgRc6f9wDI+Ruv943eDxOQCfcl3s
/ZKMUGwQOuw/SIIbOkIUbd0=
=R4M7
-----END PGP SIGNATURE-----
[View Less]
Hi Wei Li,
last year, you asked in
http://www.winehq.org/hypermail/wine-users/2004/06/0086.html
> I could not find the info regarding what operating systems > (such as AIX 5L v5.2, HP-UX 11i, Solaris Release Level > 9) will Winelib run on non-x86 machines. I'll really
> appreciate it if someone can provide my related link or
> info. I can only find the following link regarding the
> supporting OS but it does not provide Winelib's supporting
> OS info:
> http://www.winehq.…
[View More]org/site/docs/wine-faq/index 3.1.
> Under what hardware
> platform(s) and operating system(s) will Wine(Lib) run?
I'm sorry nobody got back to you -- the wine-devel
mailing list might have been a better place to ask.
I believe winelib runs on the following non-x86 operating
systems: Linux, Solaris, Mac OS X, and FreeBSD.
There's no reason in principle it couldn't run on AIX or HP/UX.
Some work has been done on an HP/UX port, but some
assembly would be required to complete it:
http://www.winehq.com/site/?issue=241#HP-UX%20Port
Cheers,
Dan
--
Wine for Windows ISVs: http://kegel.com/wine/isv
[View Less]
Hallo Martin.
This patch is giving me trouble:
>Author: Martin Fuchs <martin-fuchs(a)gmx.net>
>Date: Sat Feb 11 12:16:56 2006 +0100
>
>shell32: SHELL32_GetItemAttributes()
>- correct documentation which incorrectly claimed not to set any
> attribute bits
>- retrieve file attributes using SHGetPathFromIDListW() when they are
> not already present in the internal PIDL structures
>- add test case to show the previously wrong folder attributes when
> using …
[View More]absolute PIDLs
>- fix some memory leaks in the tests
in a couple of wine configurations that I use this leads to an infinite
lop when the openfile dialog is called. The call sequence is
SHELL32_GetItemAttributes->SHGetPathFromIDListW->ISF_Desktop_fnGetAttributesOf->SHELL32_GetItemAttributes
which repeats until the stack overflows.
Here is a part of a back trace:
| 13 0x7b8533ed SHELL32_GetItemAttributes+0x2dd(psf=0x7bc6bc28, pidl=0x7bc5e058, pdwAttributes=0x7ba5ae54) [/usr/home/projects/wine/mywine/dlls/shell32/shlfolder.c:430] in shell32 (0x7b8533ed)
| 14 0x7b83fcb8 ISF_Desktop_fnGetAttributesOf+0x148(iface=0x7bc6bc28, cidl=0x1, apidl=0x7ba5ae5c, rgfInOut=0x7ba5ae54) [/usr/home/projects/wine/mywine/dlls/shell32/shfldr_desktop.c:459] in shell32 (0x7b83fcb8)
| 15 0x7b8288cd SHGetPathFromIDListW+0x7d(pidl=0x7bc5e058, pszPath=0x7ba5b0c0) [/usr/home/projects/wine/mywine/dlls/shell32/pidl.c:1273] in shell32 (0x7b8288cd)
| 16 0x7b8533ed SHELL32_GetItemAttributes+0x2dd(psf=0x7bc6bbb8, pidl=0x7bc5e058, pdwAttributes=0x7ba5b334) [/usr/home/projects/wine/mywine/dlls/shell32/shlfolder.c:430] in shell32 (0x7b8533ed)
| 17 0x7b83fcb8 ISF_Desktop_fnGetAttributesOf+0x148(iface=0x7bc6bbb8, cidl=0x1, apidl=0x7ba5b33c, rgfInOut=0x7ba5b334) [/usr/home/projects/wine/mywine/dlls/shell32/shfldr_desktop.c:459] in shell32 (0x7b83fcb8)
| 18 0x7b8288cd SHGetPathFromIDListW+0x7d(pidl=0x7bc5e058, pszPath=0x7ba5b5a0) [/usr/home/projects/wine/mywine/dlls/shell32/pidl.c:1273] in shell32 (0x7b8288cd)
| 19 0x7b8533ed SHELL32_GetItemAttributes+0x2dd(psf=0x7bc6dd70, pidl=0x7bc5e058, pdwAttributes=0x7ba5b814) [/usr/home/projects/wine/mywine/dlls/shell32/shlfolder.c:430] in shell32 (0x7b8533ed)
A +relay,+shell log of one loop is attached below.
Running wineprefixcreate or reinstalling wine.inf does not help. On a
clean new installation there is no problem (but I like to keep using the
old stuff with a hundred or so of installed windows programs).
Any idea?
Rein.
[View Less]
Hi,
I'm trying to use a program called "siap"[1] under wine. It's the required
program to pay taxes that the Argentinian government uses.
So, it's quite important for the free software community in Argentina to be
able to use it in a free software environment. However, I haven't heard
of any real success on it, so far.
I've been trying to make it run using winetools[2], and differents versions of
wine. The furthest I've gone, has been with version 20050310 and all the
"plugins" that …
[View More]winetools provides, installed.
Only then, could I install the application, run it, switch between the
different modules (although it worked only sometimes), but I can't really use
it.
There are a couple of important widgets that seem to be incompatible with
wine. But as I'm not an expert neither in Windows nor in wine, the one I could
really track down is a TreeView widget (from comctl32.dll) (from the main
window of the program), that is not fully implemented in wine, and by using a
native comctl32.dll (I tried using the win98, winme, win2k libraries) the
widget would work but some of the other stuff, like switching
to one of the modules wouldn't.
I made a screenshot to make this clearer, the wine version[3] and the w2k
version[4].
So, what should I do next?
Is there some documentation of how to implement a certain Windows widget in
wine?
Is anybody working in this dll, or has worked on this widget?
I'd appreciate any comments.
Thanks,
[1] http://www.afip.gov.ar/programas/siap_main.asp (spanish only)
[2] http://www.von-thadden.de/Joachim/WineTools/
[3] http://gnuservers.com.ar/~maxy/wine/siap-wine.png
[4] http://gnuservers.com.ar/~maxy/wine/siap-w2k.png
--
Saludos,
/\/\ /\ >< `/
[View Less]
> it seemed that the only way to resolve it would be to
> get in between the application and any libraries, and the kernel.
>
> If wine_preloader were extended to have its own implementation of all the
> friends of mmap(), and to have its own implementation of the dynamic linker,
> then in principle it could make sure only its mmap (and not the C library's)
> is called.
You can override mmap() in wine by just changing all
the places it's called. (Having control over the …
[View More]source is
a wonderful thing.) But if you want mmap to behave
truly differently, you'd probably need to change the
kernel.
I seem to recall somebody was working on a linux
kernel module for wine that just dealt with
program loading, but I can't recall who.
Perhaps he'll surface and comment on this.
- Dan
--
Wine for Windows ISVs: http://kegel.com/wine/isv
[View Less]
I've been using and tracking Stefan Dossinger's work re: DDraw over WineD3D
and decided try and find out if IWineD3DSurface was far enough along to be
able to be used in place of IWineX11Surface for 2d applications (Hopefully to
eliminate depth conversion issues).
Short answer, no.
Long answer, Screen displays blank, trace log shows that glReadPixels at line
615 in wined3d\surface.c (LockRect) is failing with error
GL_INVALID_OPERATION. Further investigation reveals that this is because
…
[View More]glFormat is GL_COLOR_INDEX, yet the display is an RGB visual (presumably
because an indexed colour visual was not available, and this buffer is
connected directly to the screen).
I figured I'd look to the people already familiar with the WineD3D\DDraw
codebase before I tried to figure out my own solution.
--
"Most people would rather die than think; in fact, they do so." - Bertrand
Russell (1872 - 1970)
[View Less]
Hi,
On Fri, Mar 31, 2006 at 02:06:23PM +0100, Mike Hearn wrote:
> This patch gives me rock solid audio in Imperium Galactica 2, so now the
> game works perfectly.
>
> There has been discussion around this issue with respect to security in
> the past, however, regardless of what approach is adopted this code will
> have to be written anyway.
Ah, thanks, nice to see that it actually helps.
> + scheduler = SCHED_FIFO;
IMHO we should really add some smart …
[View More]detection of SCHED_ISO kernel capability
and *much* prefer to use that one then. One really wouldn't want to hang
the box...
Not to mention that SCHED_FIFO requires root, which is an absolute PITA.
Nice To Have would be support for stuff such as SCHED_IDLEPRIO and
SCHED_BATCH...
> + if (result == -EPERM)
> + {
> + static int need_warning = 1;
> +
> + if (need_warning)
> + {
> + fprintf( stderr, "\nwineserver: Failed to promote the priority of a time critical thread.\n" );
> + fprintf( stderr, "Audio may destabilise. To fix this re-run the application as root.\n\n" );
> + need_warning = 0;
> + }
> +
> + return;
> + }
Make that
static int already_warned; /* static: = 0! */
Since static uses 0 as default and you don't want to waste space in the
.bss(?) segment for an explicit 1 init.
Andreas Mohr
--
No programming skills!? Why not help translate many Linux applications!
https://launchpad.ubuntu.com/rosetta
(or alternatively buy nicely packaged Linux distros/OSS software to help
support Linux developers creating shiny new things for you?)
[View Less]
Folks,
As announced at the last Wineconf, Jeremy and myself have been working
for a few months now with the Software Freedom Law Center on a number
of legal issues concerning Wine. We've been mostly quiet about it, so
I thought I'd post a status update. There are two major tasks going on
at the moment:
1. Code audit
We are doing an audit of the code base, to make sure we have proper
records of all contributions, and spot any potentially troublesome
code. The goal is to be able to show to …
[View More]people who don't want to dig
through the source that we have done our development properly, and
that they can use Wine without fear of legal trouble.
Currently, a survey is being sent out to people we have identified as
major contributors, so that we can collect some information from them,
like employers, license agreements, that sort of thing. This will
enable us to build a complete track record for all contributions.
We are still processing the results, at this point the responses we
received cover approximately half of the code base (many thanks to
everybody who took the time to answer!). We'll be sending the survey
to more contributors in the near future to try to get as close to 100%
coverage as we can.
2. Non-profit organization
There are many advantages to having a non-profit organization for a
project, for instance to allow tax-exempt donations, or hold assets
like trademarks. However it's a lot of paperwork to do, so we never
went to the trouble of setting one up.
Now the SFLC is starting an organization called the Software Freedom
Conservancy, that will be officially launched on Monday. It's
basically an umbrella non-profit that provides services to free
software projects. By joining that organization, we will get all the
advantages of having our own non-profit, without having to do any of
the work, so that seems like a good deal...
There will also be the possibility of assigning our copyrights to that
organization, which would make it easier to enforce the license, and
provide some liability protection for developers. However this will
only be done if most developers are comfortable with it, so I'd be
interested to hear your feedback on this issue.
--
Alexandre Julliard
julliard(a)winehq.org
[View Less]
Hello List,
I had a talk to the DirectX developers of reactos on their irc channel to
discuss how Reactos and Wine can share efforts on DirectX.
(Please leave the legal issues asside for now, let us concentrate on the
technical part for now).
I didn't expect much possibility for a cooperation in such a hw-related thing
as DirextX, but Greatlord told me about the gdi / win32k problem Wine is
heading to with the current DirectX code.
According to Greatlord, Microsoft's DirectX …
[View More]implementation basically consists
of a kernel-side part in gdi.dll and win32k.sys, and a user-mode part in
ddraw.dll, d3d8.dll and d3d9.dll. The user dlls contain the Hardware
emulation layer code, and calls to the kernel for the Hardware abstraction
layer. Now that wouldn't be a problem for Wine, as applications are expected
to use the user mode dlls, and using the kernel interface is highly
discouraged by Microsoft. However, there are a few apps out there which
access the kernel interface directly, and Greatlord told me that he knew
about a few companies which plan to use it to gain speed improvement.
Expectedly, such apps won't work on Wine.
My long term suggestion is to move the Direct3D->OpenGL translation code from
WineD3D to gdi and a win32k sys, and write ddraw.dll, d3d8.dll and d3d9.dll
to use that interface. The user mode dlls can be shared with Reactos, and
from a technical point of view, even Microsoft's DirectX dlls can be used on
Wine(including the hardware emulation layer).
I know that this is not easy to achieve. The kernel interface is poorly
documented, and Greatlord has spent a lot of effort to verify the docs and to
write a better documentation of the interface. Apps using the kernel
interface should be considered broken, and I don't give them a long lifetime
as the interface changes from Windows version to Windows version(According to
Microsoft, Greatlord says it didn't change since NT(2K?) ). Should we go this
way and implement the kernel Direct3D interface? If so, I consider this
something post-1.0, and we should definitely see what changes Vista brings.
Another thing we discussed was DirectInput. ReactOS uses wines dinput.dll,
with improvements which gets the sdk demos and some nasty games working. I
can see if I can merge the changes to Wine.
[View Less]
I've been hearing rumblings about people using Wine
to run windows photoshop plugins on Linux Gimp,
but hadn't seen anything concrete. Well, here it is:
http://www.gimp.org/~tml/gimp/win32/pspi.html
Have a look. Congratulations, Wine!
- Dan
--
Wine for Windows ISVs: http://kegel.com/wine/isv
On Thu, 30 Mar 2006, Wine Bugs wrote:
> http://bugs.winehq.org/show_bug.cgi?id=1181
>
> ------- Additional Comments From Speeddymon(a)gmail.com 2006-30-03 10:26 -------
> Peter, I'm not sure if you ever did subscribe to wine-devel, but you did mention
> that wine could possibly reuse parts of your keysym implementation. Could you
> email the list (even if you dont scubscribe) and let them know about this bug,
> and see if anyone is willing to take a look at it. Just make …
[View More]sure you let them
> know you aren't subscribed, if you aren't, and to CC you on replies.
Hi, now you know about this bug. As the comment says, it might be possible
to reuse some parts from the rdesktop implementation.
I'm not saying that it will be easy, though. To be honest, I think bug
4923, and many others, are more important. Instead of fixing Wine, it
might be possible to enhance Xvnc so that it can "emulate" a physical
Xserver with a certain physical keyboard.
Regards,
--
Peter Åstrand ThinLinc Chief Developer
Cendio http://www.cendio.se
Teknikringen 3
583 30 Linköping Phone: +46-13-21 46 00
[View Less]
Hi all, this is a call for volunteers. I am hoping that certain developers
participating in another thread are willing to rewrite the keyboard code,
but we need people to test. If you are interested, please reply here saying
that you are interested, and what kind of keyboard you use, as well as the
layout you use under X. I will be creating a wiki page for this project
once the people who will be taking on this rewrite confirm that they will do
so, and will post the link to this thread as …
[View More]soon as it is created.
The purpose of this rewrite is to (hopefully) fix all of the problems people
have with key mappings, characters not showing up as expected, race
conditions, characters not showing up at all, etc, and hopefully allow us to
close out many of the bugs in bugzilla having to do with the keyboard.
Thanks all in advance
Tom
[View Less]
OK, I'm tired now but this is a new release an it owns ;). It should
be quite stable but I didn't test it. So what has changed:
0.31 One more Release, I'm glad about this one
- Some smaller an greater Fixes
- After Compiling, the Script creates a helperfile to help mode 4
- Sections in Logfile
- Trap included to handle ctrl+c
- Implemented a small sleeper to give you a chance to stop the
script before it starts to clean the source
This is one of the …
[View More]last versions. The last version will be called 1.0.
(maybe the next one?)
If you miss a feature... write to the mailinglist.
[View Less]
The recent changes to the desktop have revealed a problem with recursive
processing of X messages. The problem started to manifest with commit
1a4f6e579b6aab685fae2e649fd5accee7ec0b4f (7th March). A symptom is a stack
that looks like this:
<application Window procedure>
WINPROC_wrapper
...
CallWindowProcW
...
SendMessageW
X11DRV_SetWindowPos
SetWindowPos
X11DRV_ConfigureNotify
process_events
X11DRV_MsgWaitForMultipleObjectsEx
wait_message_reply
…
[View More]send_inter_thread_message
SendMessageTimeoutW
SendMessageW
send_parent_notify
DestroyWindow
In other words, a destroy notification is being sent to the parent window with
SendMessageW, and before that message returns an unrelated X message is
processed. Under Windows the equivalent could never happen - if a thread is
in SendMessage(), the only messages that can be delivered to it are ones sent
by SendMessage() from another thread.
The consequences of this can be unpleasant if the code that processes (in this
case a window movement notification) the message interferes with state that
is being dealt with in earlier stack frames.
wait_message_reply calls X11DRV_MsgWaitForMultipleObjectsEx with:
res = USER_Driver->pMsgWaitForMultipleObjectsEx( 1, &server_queue,
INFINITE, QS_ALLINPUT, 0 );
The brute-force approach of changing this to the following makes the
application work, but gives rise to some pack_message FIXMEs (for WM_NCPAINT
and WM_ERASEBKGND), and since this is an extremely sensitive piece of code to
change I thought it best left to people with more familiarity with it.
--
Troy Rollo - wine(a)troy.rollo.name
[View Less]
Tomas Carnecky <tom(a)dbservice.com> writes:
> This patch doesn't change any logic or C sourcecode, it only moves the
> X11DRV escape code definition to one common header file. Currently the
> definitions are spread over several C source files, and even there the
> definitions differ from file to file. I don't see anything wrong with
> this patch unless you *want* to have it difficult to maintain the code.
Actually, that's more or less what we want. That sort of inter-dll
…
[View More]dependencies should be strongly discouraged, and we don't want to add
more of it than strictly necessary; as far as possible we also don't
want dlls to depend on private headers, so copying a few things across
is the preferred approach. If it becomes a problem it means something
is wrong with our implementation.
--
Alexandre Julliard
julliard(a)winehq.org
[View Less]
Hi,
I'm not online too often. :( So, I thought the patch for Linux must
already be in CVS. It is not.
The patch can be found here:
http://www.winehq.org/pipermail/wine-patches/2006-March/025228.html
However, the patch only works for Linux. Please, let me know if you're
using a different platform, as it is very likely that it can be made
to work too, but I won't send patches which I can't test.
To the wine-devel list: Why was the patch rejected, anyway?
Petr Tesarik
On 03/29/06 at 09:35:…
[View More]04 (-0800), Dan Kegel wrote:
> On 3/29/06, Petr Tesarik <hat(a)tesarici.cz> wrote:
> > No, this is not normal. This problem was introduced on the i386
> > architecture, when floating point registers were added to winedbg.
> > Currently, there are two pending patches by me, one which fixes the
> > problem on Linux, and another which fixes it on all platforms but is
> > most likely wrong.
> >...
> > Anyway, see also my next email.
>
> Looking forward to it.
> Can you give me the URL of the i386 patche in the wine-patches archive?
> Thanks,
> Dan
>
[View Less]
Sending here until wine-patches stops eating my email.
IMHO this would best be done in get_obj_from_handle in the server,
but this approach is what the registry APIs do and what Rob suggested,
so here it is.
diff --git a/dlls/kernel/process.c b/dlls/kernel/process.c
index 4263a22..d5017c4 100644
--- a/dlls/kernel/process.c
+++ b/dlls/kernel/process.c
@@ -2265,6 +2265,8 @@ HANDLE WINAPI OpenProcess( DWORD access,
attr.SecurityQualityOfService = NULL;
attr.ObjectName = NULL;
+ …
[View More] if (GetVersion() & 0x80000000) access = PROCESS_ALL_ACCESS;
+
status = NtOpenProcess(&handle, access, &attr, &cid);
if (status != STATUS_SUCCESS)
{
[View Less]
Hey,
As you've probably noticed, I've been working on implementing advpack
for a couple months now; a lot of progress has been made, and I'm glad
to say that the end is in sight. The rest of this email details the
game plan for finishing advpack.
advpack has five main install functions: DoInfInstall, ExecuteCab,
LaunchINFSection, LaunchINFSectionEx, and RunSetupCommand. They all
basically do the same thing with minor differences in functionality.
ExecuteCab extracts the files to install …
[View More]from a cab archive,
LaunchINFSectionEx provides backup and rollback capability, and
RunSetupCommand can also launch executables. When installing an INF
section, advpack calls setupapi to install the base INF commands, such
as CopyFiles and AddReg. After this, advpack parses the Advanced INF
for advanced commands that are only installable when using advpack.
These commands include:
Values:
RequiredEngine - Use either setupapi or setupx, we will ignore it.
CustomDestination - assigns ldids to extra directories.
SmartReboot - same reboot options as LaunchINFSection.
Cleanup - deletes the INF when the install/uninstall is finished if this is 1.
CheckAdminRights - check if the user is admin if this is 1.
Actions:
RegisterOCXs
UnregisterOCXs
BeginPrompt
EndPrompt
RunPreSetupCommands
RunPostSetupCommands
DelDirs
PerUserInstall
Backup/Rollback:
ComponentName
ComponentVersion
BackupReg
PreRollBack
BackupPath
Internally, there will be three main install functions: install_init,
which will open the INF, make sure it's legit, and other
initializations, spapi_install, which will call setupapi to install
the base INF commands, and adv_install, which will parse the install
section and run the provided commands. Each advanced command will be
implemented by a function of similar name, e.g., RegisterOCXs would be
implemented by the function register_ocxs, etc. All the command
functions will be in a hash map, the key being the command name, the
value being a pointer to the function that implements the command.
adv_install will use setupapi to parse the entries of the install
section, calling the function returned by a query to the hash map.
According to INF Web [1], some commands are run before others, so
there will probably be three or four maps, the functions in the maps
grouped according to the order in which the commands should be run.
For example, RunPreSetupCommands is to be executed after the
BeginPrompt command, so begin_prompt would be in the phase 1 map, and
run_pre_setup_commands would be in the phase 2 map. We would call the
parser like so:
run_adv_commands("InstallSection", phase1_map);
run_adv_commands("InstallSection", phase2_map);
run_adv_commands("InstallSection", phase3_map);
If a command in the install section is not in the map, we just ignore it.
This is The Plan so far, so if anyone has any ideas or suggestions,
I'd love to hear from you.
Thanks,
James Hawkins
[1] http://www.winpack.org/petr/INF_web/
[View Less]