Re: WINEGATE.DLL: Wine gateway to native Unix libraries
I don't want to be rude, but I have better things to do than propagandize my solution. We can live without such library in Wine, it would just require us to maintain separate libraries for different libc or wine versions. Having it in wine distribution would solve this problem smoothly, reducing our task only to maintain native Linux shared lib for hardware access. If anything changes in your position, let me know, I am willing to help with it. Martin So now and then things come by which would be useful for some Wine users / developers but which aren't suited for inclusion in Wine. Nonetheless I think we need a place where such things can be stored. Perhaps that should be done on the Wine wiki (not sure if we can upload files to there). I can imagine that we should put a porting page there and mention winelib and winegate. Roderick -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01
Re: mshtml: Correctly test to see if PutProperty_CLASSIDPROP is called
Ignore this, the subject is wrong. Alistair Leslie-Hughes leslie_alist...@hotmail.com wrote in message news:4997db01.1000...@hotmail.com... Hi, Changelog: mshtml: Correctly test to see if PutProperty_CLASSIDPROP is called. Best Regards Alistair Leslie-Hughes From 14267df8f532c7acc7cc184c3c1e020639ca8702 Mon Sep 17 00:00:00 2001 From: Alistair Leslie-Hughes leslie_alist...@hotmail.com Date: Fri, 6 Feb 2009 20:03:47 +1100 Subject: [PATCH] Corrected tests To: wine-patches wine-patc...@winehq.org --- dlls/urlmon/tests/url.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dlls/urlmon/tests/url.c b/dlls/urlmon/tests/url.c index c062cf8..e5895c4 100644 --- a/dlls/urlmon/tests/url.c +++ b/dlls/urlmon/tests/url.c @@ -313,7 +313,7 @@ static DWORD WINAPI thread_proc(PVOID arg) CHECK_CALLED(Obj_OnProgress_BEGINSYNCOPERATION); CHECK_CALLED(CreateInstance); CHECK_CALLED(PutProperty_MIMETYPEPROP); -CLEAR_CALLED(PutProperty_CLASSIDPROP); +CHECK_CALLED(PutProperty_CLASSIDPROP); CHECK_CALLED(Load); CHECK_CALLED(Obj_OnProgress_ENDSYNCOPERATION); CHECK_CALLED(OnObjectAvailable); @@ -612,7 +612,7 @@ static HRESULT WINAPI Protocol_Start(IInternetProtocol *iface, LPCWSTR szUrl, CHECK_CALLED(Obj_OnProgress_BEGINSYNCOPERATION); CHECK_CALLED(CreateInstance); CHECK_CALLED(PutProperty_MIMETYPEPROP); -CLEAR_CALLED(PutProperty_CLASSIDPROP); +CHECK_CALLED(PutProperty_CLASSIDPROP); CHECK_CALLED(Load); CHECK_CALLED(Obj_OnProgress_ENDSYNCOPERATION); CHECK_CALLED(OnObjectAvailable); -- 1.5.4.3
Re: Updated cebit presentation. Looking for ideas...
A before/after of Safari with corefonts might also be good, to show an example of what winetricks can fix. Heh. Safari without corefonts hangs. Hard to capture that in a screenshot :-) you can do that with steam :P
Re: WINEGATE.DLL: Wine gateway to native Unix libraries
On So, 2009-02-15 at 01:02 +0100, Martin Hinner wrote: - It's already present in Wine: libwine.dll has exports for wine_dlopen/wine_dlclose/wine_dlsym please read: libs/wine/loader.c I saw it, but I don't understand how is it exported to the Win32 world, i.e. how do I import these using GetProcAddress() Win32 API ? As I already mentioned: libwine.dll has exports for wine_dlopen/wine_dlclose/wine_dlsym Just use this infos: hdll = LoadLibraryA(libwine.dll); wine_dlopen = GetProcAdress(hdll, wine_dlopen); wine_dlsym = GetProcAdress(hdll, wine_dlsym); wine_dlclose = GetProcAdress(hdll, wine_dlclose); Keep attention on the calling convention. find /usr/src/wine* -name '*.spec' | xargs -n 10 grep dlopen did not reveal anything except winegate.dll :-). A *.spec is used as input for winebuild to build a *.def. Keep it as simple as possible and use only grep: grep -r dlopen wine-source/libs/ You find the exported functions in libs/wine/wine.def -- By by ... Detlef
Re: WINEGATE.DLL: Wine gateway to native Unix libraries
Detlef,
On Sun, Feb 15, 2009 at 12:50 PM, Detlef Riekenberg wine@web.de wrote:
Just use this infos:
hdll = LoadLibraryA(libwine.dll);
wine_dlopen = GetProcAdress(hdll, wine_dlopen);
wine_dlsym = GetProcAdress(hdll, wine_dlsym);
wine_dlclose = GetProcAdress(hdll, wine_dlclose);
The LoadLibraryA call does not work for me. Tried with many names
(wine,libwine, etc) and wine is according to strace always trying to
open /usr/lib/wine/{lib}libwine.dll.so which is not obviously present.
M.
AppDB new design: Top 10s still look ugly
Hello, Bug #16466 is declared as fixed. but it isnt. my patch should do something else. I wanted let each top 10 in its own color(platin, gold or bronce) and not to have the platin-look for all. anything went wrong while using my patch. maybe the other patch went in, too? It should be this style: http://www.funplugged.bplaced.net/appdb/
Re: AppDB new design: Top 10s still look ugly
hi andré, alex didn't apply your patch. he just fixed the .css to give it the same style as it had before. 2009/2/15 André Hentschel n...@dawncrow.de Hello, Bug #16466 is declared as fixed. but it isnt. my patch should do something else. I wanted let each top 10 in its own color(platin, gold or bronce) and not to have the platin-look for all. anything went wrong while using my patch. maybe the other patch went in, too? It should be this style: http://www.funplugged.bplaced.net/appdb/
Re: [patch but not quite ready] NamedPipes messagemode
On Sat, Feb 14, 2009 at 7:02 PM, Luke Kenneth Casson Leighton luke.leigh...@googlemail.com wrote: http://bugs.winehq.org/show_bug.cgi?id=17195 with only one significant bug - some memory corruption - the semantics are now correct in the namedpipe messagemode patch. found it. as suspected, utilising the same critical section fd_cache_section as in ntdll/file/server.c this issue went away. it wasn't memory corruption at all, it was the use of the wineserver socket to send filedescriptors using ioctls: server_get_named_pipe_fd() was picking up a filedescriptor that was intended for server_get_unix_fd() and vice-versa. so - fixed! working! ... sort-of :) the one remaining fly in the ointment, which i'm going to ignore, is demonstrated by threadread and threadwrite tests: running unix out of socketpair file handles. 20 writes by 5 threads are queued up by e.g. threadwrite, resulting in a whopping two _hundred_ filedescriptors being handed out. reading this: http://msdn.microsoft.com/en-us/library/aa365150.aspx describes how use of a NamedPipe should block on write: The write operation will block until the data is read from the pipe so that the additional buffer quota can be released. Therefore, if your specified buffer size is too small, the system will grow the buffer as needed, but the downside is that the operation will block. If the operation is overlapped, a system thread is blocked; otherwise, the application thread is blocked. ignoring the bollocks about buffer sizes, and buffer quotas, which give an indication of how microsoft internally implements NamedPipes, it's clear then that blocking the application is perfectly acceptable. exactly how this is to be achieved is yet to be determined, but as i keep mentioning, it's highly likely that a per-file-handle mutex is required. quick tests: 1) test1, shortread, send2recv2: pass. 2) reducing BUF_SIZE in the tests code to 128 works, threadread and threadwrite: success 3) removing the interim use of ncacn_ip_tcp in SVCCTL and returning to ncacn_np: success. 4) going back to running a simple python2.7.exe multiprocessing tests, which use message-mode named pipes, the whole damn _point_ of this exercise: success 5) running MSYS: fail. bugger. a veery cursory look at the output, it looks like it's a non-message-mode pipe. arg. no surprise there, then. *sigh*. will let you know how i get on. l.
Re: AppDB new design: Top 10s still look ugly
Ricardo Filipe schrieb: hi andré, alex didn't apply your patch. he just fixed the .css to give it the same style as it had before. 2009/2/15 André Hentschel n...@dawncrow.de mailto:n...@dawncrow.de Hello, Bug #16466 is declared as fixed. but it isnt. my patch should do something else. I wanted let each top 10 in its own color(platin, gold or bronce) and not to have the platin-look for all. anything went wrong while using my patch. maybe the other patch went in, too? It should be this style: http://www.funplugged.bplaced.net/appdb/ Hi Ricardo, but its not the same as before, look at my attachment in bug #16466, do you see something else then me?
Re: AppDB new design: Top 10s still look ugly
Ricardo Filipe schrieb: 2009/2/15 André Hentschel n...@dawncrow.de mailto:n...@dawncrow.de Ricardo Filipe schrieb: hi andré, alex didn't apply your patch. he just fixed the .css to give it the same style as it had before. 2009/2/15 André Hentschel n...@dawncrow.de mailto:n...@dawncrow.de mailto:n...@dawncrow.de mailto:n...@dawncrow.de Hello, Bug #16466 is declared as fixed. but it isnt. my patch should do something else. I wanted let each top 10 in its own color(platin, gold or bronce) and not to have the platin-look for all. anything went wrong while using my patch. maybe the other patch went in, too? It should be this style: http://www.funplugged.bplaced.net/appdb/ Hi Ricardo, but its not the same as before, look at my attachment in bug #16466, do you see something else then me? it's not bug #16466 for sure :P i don't really remember how it was before, and i'm not too fond of having gold and silver apps with the white too, but it serves it's function fine... you'd better talk to alex on that to be sure what's the objective. sorry, it was #16442
Re: [patch but not quite ready] NamedPipes messagemode
5) running MSYS: fail. found it: rxvt.exe is looking for libX11.dll (!!) which is nothing to do with NamedPipes. running c:/msys/bin/sh.exe --login -i is: success.
http://wiki.winehq.org/NamedPipes - documenting the samba / wine NamedPipes integration
i've been updating this page with relevant information that is part requirements specification, part documentation. of particular relevance is the lack of support (in both tng and samba 3) for transferring SetNamedPipeHandleState semantics, although the stub functionality inside tng (smbd/pipe-proxy.c) at least records the NP message-mode flags, and then _completely_ ignores them ha ha :) exactly how this is to be implemented is unclear, and to be absolutely honest, by far the simplest-sounding approach may be to actually compile samba up as a win32 app! under such circumstances, it would be incredibly easy to then call the wine-emulated NamedPipe win32 functions CreateNamedPipe, SetNamedPipeHandleState etc. etc. given that samba tng has _already_ successfully been ported to win32, it has a head start here. and in that regard, ReactOS has it made, done and dusted! the alternative is... gaahd, i dunno... messy, to say the least, and *shudder* an mmap'd tdb is sounding _really_ attractive. tell me if this sounds reasonable. basically, a mini-wineserver protocol - a mini-SMB protocol - is required. commands to send, receive, setnamedpipestate, waitnamedpipestate and close. all required. * samba 3 / tng create or access named pipes as emulations over unix domain sockets, including sending a security context. in samba 3, that's called a SamInfo3, but it looks suspiciously like a NETLOGON NET_USER_INFO_3) and in tng it's a NET_USER_INFO_3... so... yep, it looks like just the name has been changed. * a program wants to create or access a named pipe; it asks wineserver (via a new function) to create or open up a unix domain socket. the locations will be the same. i.e. tng / samba3's unix domain socket pipe locations same as wineserver's. * sending / receiving of the security context blob is done in the dlls NOT in wineserver, so as to avoid blocking wineserver. * read, write, snphs, wnphs are all done with a 2-byte command prefix, followed by parameters, followed by data. exactly the same as is done in SMB and in wineserver. ... you know... if SMB wasn't so damn complicated i'd say bugger it, just send the SMBs to Wine, for _it_ to sort out!! in fact, with cliffsd's auto-generated SMB parsing code, that might even still be a valid option, given that the relevant code for parsing the SMBs is public domain. what do people think? does this sound like a reasonable proposition - a mini SMB/wineserver protocol - for use for inter-communication between wine and samba in order to exchange named pipe traffic? l.
Re: [2/3] WineD3D: Add a debug function for surface locations
2009/2/14 Stefan Dösinger ste...@codeweavers.com:
+const char *debug_surflocation(DWORD flag) {
+switch(flag SFLAG_LOCATIONS) {
+case SFLAG_INSYSMEM:return SFLAG_INSYSMEM;
+case SFLAG_INDRAWABLE: return SFLAG_INDRAWABLE;
+case SFLAG_INTEXTURE: return SFLAG_INTEXTURE;
+case SFLAG_INSRGBTEX: return SFLAG_INSRGBTEX;
+
+case SFLAG_INSYSMEM | SFLAG_INDRAWABLE: return SFLAG_INSYSMEM |
SFLAG_INDRAWABLE;
+case SFLAG_INSYSMEM | SFLAG_INTEXTURE: return SFLAG_INSYSMEM |
SFLAG_INTEXTURE;
+case SFLAG_INSYSMEM | SFLAG_INSRGBTEX: return SFLAG_INSYSMEM |
SFLAG_INSRGBTEX;
+
+case SFLAG_INDRAWABLE | SFLAG_INTEXTURE: return SFLAG_INDRAWABLE
| SFLAG_INTEXTURE;
+case SFLAG_INDRAWABLE | SFLAG_INSRGBTEX: return SFLAG_INDRAWABLE
| SFLAG_INSRGBTEX;
+
+case SFLAG_INTEXTURE| SFLAG_INSRGBTEX: return SFLAG_INTEXTURE
| SFLAG_INSRGBTEX;
+
+case SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INTEXTURE:
+return SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INTEXTURE;
+case SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INSRGBTEX:
+return SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INSRGBTEX;
+case SFLAG_INSYSMEM | SFLAG_INTEXTURE | SFLAG_INSRGBTEX:
+return SFLAG_INSYSMEM | SFLAG_INTEXTURE | SFLAG_INSRGBTEX;
+case SFLAG_INDRAWABLE | SFLAG_INTEXTURE | SFLAG_INSRGBTEX:
+return SFLAG_INDRAWABLE | SFLAG_INTEXTURE | SFLAG_INSRGBTEX;
+
+case SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INTEXTURE |
SFLAG_INSRGBTEX:
+return SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INTEXTURE |
SFLAG_INSRGBTEX;
+
+default: return Unknown location flag combination;
+}
+}
I think using wine_dbg_sprintf() would be a lot more practical.
Re: [3/3] WineD3D: Pass the requested srgb flag to PreLoad
2009/2/14 Stefan Dösinger ste...@codeweavers.com: +SRGB_DONTKNOW = 0,/* Uses the cached value(e.g. external calls) */ SRGB_ANY or SRGB_EITHER is probably a nicer name. Do the enum elements need explicit values? You can probably drop the typedef as well, I don't think it adds anything useful. (I already mentioned some reservations about the extent of the changes to the internal interfaces for sRGB texture duplication on IRC, but lets merge it anyway and see where it goes.)
Re: Updated cebit presentation. Looking for ideas...
On Sat, Feb 14, 2009 at 04:49:03PM -0800, Dan Kegel wrote: I've been slowly finishing my cebit presentation. The current draft is at http://kegel.com/cebit/ It now talks briefly about winetricks, and uses firefox and safari as examples of installing and running platinum and bronze apps. It also talks more about support, since a windows admin I showed it to said windows admins were generally scared of trying to support open source apps. If anyone has suggestions for how to make this presentation more appealing/informative/convincing to newbies who are only familiar with windows, please let me know. Also, if anyone can tell my why firefox doesn't show the Windows logo until you refresh sometimes, I'd be grateful. Maybe it's because the same image is used twice in the same page? Btw, I have run my last 3 Wine presentations in OpenOffice_org 2.4 for Win32. Did not give much crowd h effect though. Ciao, Marcus
Re: WINEGATE.DLL: Wine gateway to native Unix libraries
On Sun, Feb 15, 2009 at 3:37 AM, Roderick Colenbrander thunderbir...@gmx.net wrote: I don't want to be rude, but I have better things to do than propagandize my solution. We can live without such library in Wine, it would just require us to maintain separate libraries for different libc or wine versions. Having it in wine distribution would solve this problem smoothly, reducing our task only to maintain native Linux shared lib for hardware access. If anything changes in your position, let me know, I am willing to help with it. Martin So now and then things come by which would be useful for some Wine users / developers but which aren't suited for inclusion in Wine. Nonetheless I think we need a place where such things can be stored. http://code.google.com/p/winezeug/ ? -- -Austin
Re: Updated cebit presentation. Looking for ideas...
On Sun, Feb 15, 2009 at 1:26 PM, Marcus Meissner mar...@jet.franken.de wrote: Btw, I have run my last 3 Wine presentations in OpenOffice_org 2.4 for Win32. Did not give much crowd h effect though. I guess I'm not trying to impress, I'm trying to reassure. So maybe doing it in MS Office 2003 or 2007 in wine or crossover would be optimal.
Re: http://wiki.winehq.org/NamedPipes - documenting the samba / wine NamedPipes integration
Hi Luke, does this sound like a reasonable proposition - a mini SMB/wineserver protocol - for use for inter-communication between wine and samba in order to exchange named pipe traffic? Well, I think we have to crawl before we can walk. I think it's more important that we have a working local named pipe implementation before we start thinking about SMBs from Wine to a remote machine. Usually, having a specific app in mind really helps drive an implementation, too. So, for instance, local message-mode named pipes will help Python run in Wine: cool. There are of course many apps that might want to do SMBs over named pipes.. but having a specific one we're trying to fix, along with someone motivated to get it working, helps. --Juan
Re: Updated cebit presentation. Looking for ideas...
2009/2/15 Dan Kegel d...@kegel.com On Sun, Feb 15, 2009 at 1:26 PM, Marcus Meissner mar...@jet.franken.de wrote: Btw, I have run my last 3 Wine presentations in OpenOffice_org 2.4 for Win32. Did not give much crowd h effect though. I guess I'm not trying to impress, I'm trying to reassure. So maybe doing it in MS Office 2003 or 2007 in wine or crossover would be optimal. yeah using MS office would give the cool factor that openoffice lacks through wine since it has the native counterpart...
Wine talk on FOSDEM
Hi, A week ago I went to Bruessel / Bruxelles in Belgium to the largest opensource developer conference in Europa, FOSDEM 2009. openSUSE has a developer room there the last years and we fill our time by holding talks, mostly concerning openSUSE and stuff that we do for the distribution and what our developers do. So the openSUSE organizers asked me to hold a talk on Wine this year, after my LinuxTag talk was so well received. I expected that like 20-30 people would show up, but it actually were around 110 according to our camera guy and they filled up the room. I have no idea why Wine is so interesting though. I gave a basic introduction and overview mostly and in the end tried to demo iTunes (failed, because installation was not successful in preparation) and demoed Heroes of Might and Magic III (successful). If you want to watch my 45 minutes: http://tube.opensuse.org/fosdem09/fosdem09_day2_03-wine.ogg (196MB) And my slides are here (feel free to reuse): http://files.opensuse.org/opensuse/en/0/05/Fosdem2009-wine.pdf http://files.opensuse.org/opensuse/en/0/05/Fosdem2009-wine.odp I also said hi to some ReactOS guys. Funnily all of them in suit and tie. :) Ciao, Marcus
Re: 1.1.15 failing to build -- what changed?
2009/2/16 Hin-Tak Leung hintak_le...@yahoo.co.uk:
--- On Sun, 15/2/09, Ben Klein shackl...@gmail.com wrote:
2009/2/15 Hin-Tak Leung hintak_le...@yahoo.co.uk:
--- On Sun, 15/2/09, Ben Klein
shackl...@gmail.com wrote:
2009/2/15 Hin-Tak Leung
hintak_le...@yahoo.co.uk:
I have no idea why suddenly at wine 1.1.15 it
requires
the
x86_64-redhat-linux-{as,ld,nm} form of the
binutils
tools. It seems to treat x86_64 suddenly as a
cross-compiling environment.
Are you sure nothing in the build environment just
happened
to change
in the last 2 weeks or so?
Well, I do my weekly fedora update, so a few hundred
MB changes weekly. Given that this problem happens with both
Debian/Ubuntu systems and fedora, this week... and I have
had my rpmbuild system working smoothly for about a year...
If I am going to guess, I think the change has
something to do with cross-compiling, instead of just the
occasional -m32 .
scguy318 just brought this to my attention on IRC:
http://bugs.winehq.org/show_bug.cgi?id=17340
Argh... the original reporter of that bug seems to be rather mistaken - there
is no need to have a separate cross-compile tool chain on 64-bit fedora
(which I am also using) to build 32-bit applications. Just passing -m32 to
both the compiler (CFLAGS for c , CXXFLAGS for c++ code and FFLAGS for
fortrans) and the linker (LDFLAGS) would do.
So to make it work for one person's peculiar build environment, everybody
else's normal environment has to break...
Only when using --target and --host flags (which I don't use because I
have chroots, so I didn't notice the change), but I get your point.
Re: Wine talk on FOSDEM
Am Sonntag, 15. Februar 2009 23:03:27 schrieb Marcus Meissner: Hi, And my slides are here (feel free to reuse): http://files.opensuse.org/opensuse/en/0/05/Fosdem2009-wine.pdf Just skimmed over them out of curiosity, found one mistake: GameGuard does not work because it is a rootkit that doesn't work with Wine by design.
Re: Wine talk on FOSDEM
2009/2/15 Stefan Dösinger stefandoesin...@gmx.at Am Sonntag, 15. Februar 2009 23:03:27 schrieb Marcus Meissner: Hi, And my slides are here (feel free to reuse): http://files.opensuse.org/opensuse/en/0/05/Fosdem2009-wine.pdf Just skimmed over them out of curiosity, found one mistake: GameGuard does not work because it is a rootkit that doesn't work with Wine by design. yeah i was just looking at that too... all those online protection libraries still don't work, which i think is the next step we have to take on games :p also the game wasn't heroes of might and magic III , it was dark messiah :P the german accent gives the presentation a new horizon :D good job. :)
[Fwd: Windows on Linux App of the Year]
We've won the 'Windows on Linux' award of the year on LinuxQuestions.org again (by quite a large margin, I might add). Woohoo! Cheers, Jeremy ---BeginMessage--- Jeremy, Hope you've been well. It's my pleasure to inform you that wine has once again been selected as the Windows on Linux App of the Year in the 2008 LinuxQuestions.org Members Choice Awards. Congratulations! For more information, visit: http://www.linuxquestions.org/questions/2008-linuxquestions.org-members-choice-awards-83/windows-on-linux-app-of-the-year-695655/ I've attached an official website badge. If you have any questions, let me know. --jeremy http://jeremy.linuxquestions.org/ attachment: windows-linux-app-wine.png---End Message---
Debian Etch, Lenny and Squeeze packages
Debian Lenny has gone stable. YAY! I've already got chroots and my build scripts set up for Debian Squeeze, which is the new testing, so I'll be able to produce packages of Wine for Squeeze without trouble, but there are some issues I'd like comment on. 1) I will not supply packages for Etch/amd64 (this used to be a TODO for me). No negotiation on this, but I am willing to assist people to compile/package it themselves if there's a good reason for not upgrading to Lenny. 2) I'll still build Etch/i386 packages (because it's damn easy for me to do so), but how long should this go on for? Ideally, we should encourage people to upgrade to Lenny. 3) Do we want to set up a Squeeze repository with 1.1.15 in it, or should we wait until the next release to set up a Squeeze repository? If the former, I will build packages specifically on/for Squeeze - best to do it this way for maximum compatibility. Ideally, I'd like a standardised policy on points #2 and #3, so that we know what's going on for the next release of Debian (I know, long-term planning). Scott, I'd value your opinion too, even though you only do Ubuntu packages now.
Re: [Fwd: Windows on Linux App of the Year]
2009/2/16 Jeremy White jwh...@codeweavers.com: We've won the 'Windows on Linux' award of the year on LinuxQuestions.org again (by quite a large margin, I might add). This really does sound like an award set up for Wine to win. What are the other options? VMs? Crossover (which is basically Wine with a little proprietary stuff) or Cedega (which Wine outperforms in many ways)?
office 2007 student trial downloaded, activated, and started ok!
Golly, Wine must be getting good. The student trial (though not the pro trial) of office 2007 from http://office.microsoft.com seems to install, activate, and start properly with no hacks at all. Can't edit the default document though, it says selection locked. Guess I'll try the overrides listed in the appdb. I'm just blown away that the whole download experience worked. There were two nits: 1) no progress indication other than on the taskbar, and 2) the file was downloaded to $HOME/%MYDOCS%. Are we not expanding something properly?
Re: advapi32: GetNamedSecurityInfoExA Stub
Paul Bryan Roberts pbronline-w...@yahoo.co.uk wrote: I guess this stub falls in to the 'not obviously correct' category. I could do with some feedback on what might be an acceptable patch. It appears that GetNamedSecurityInfoExA signature doesn't match the MSDN/PSDK one. Also it's a common practice to simultaneously add both A and W versions, and add prototypes to an appropriate .h file. -- Dmitry.
