Re: [QCAP] patch 4, Adding enumPins object
Changelog - dlls/qcap/Makefile.in - dlls/qcap/enumpins.c Add IEnumPins object for use by other class objects. This is taken from quartz with only minor adaptions. Rolf Kalbermatter +WINE_DEFAULT_DEBUG_CHANNEL(quartz); Shouldn't that be qcap ? Cheers, Paul.
Re: UT2003 regression, Windowing problem
On Mon, 09 May 2005 22:43:49 +0100, Ann and Jason Edmeades wrote: So should there have been an action as a result of the WM_PAINT, and is it valid for it not to occur (ie is wine overdoing the assumption on redrawing) Notes has the same problem. Last time I talked to The Director about it he said doing nothing in WM_PAINT was invalid and indeed, doing that on Windows goes into an infinite loop. Most puzzling. There seems to be a magic combination of things you can do that make it not go into this loop ... not sure. Looks like I have 2 more apps: Empire Earth and MS Office 2003. Empire Earth locks during startup(before reaching it's usual problems), and MS Office 2003 blocks when showing the file open/save dialog. Adding a break in the child==prev path of update_now fixes them too. Stefan
Re: [Fwd: Re: Commercial support]
On Tue, 10 May 2005 11:02, StartCom Ltd. wrote: Or maybe just because of it, there is a need for commercial support, or somebody might need that support. If it would be running, by just clicking on the executable, no support is really needed, at least not for standard applications. IBM does very well know the existents of Wine (they even acknowledged that by themselves lately), but may very well not support it, because of inter-relation with MS. As of now (just a guess), they don't want to get into more hot water right now I can verify that from a private conversation I had with an IBM employee last year at the local LUG's installfest. He informed me that because IBM has this sort of relationship with Microsoft, they are not free to get involved in anything that would make use of the MS Windows knowledge they have gained from that relationship. Stands to reason. But it's a pity. Wesley Parish gslink wrote: Go to the Wine HQ site and click on applications database. If you need more applications check the listed links. This is a problem with every development effort and nobody is blaming anybody. The larger the effort the worse it gets. This is probably the worst problem both Microsoft and IBM have with code. If you change anything in Wine something somewhere will probably quit running. This is simply the price of progress. My comment, and it is not a criticism, is that Wine still has rough edges. Eventually these will go away but for now, you can't simply load Wine into Linux and blindly start loading in applications. The more complex the application the more likely it needs setup. As versions progress setup procedures change and as a result things quit running. Microsoft Office doesn't run without setup and neither do many of the older games such as Alice or Rune. Even things like Warcraft come and go. This is not a criticism it is just the way things are and that is why I think it is too early to start thinking about commercial support. What somebody needs to do now is to get a relationship with IBM similar to the one that Eclipse has. IBM has a problem currently because there is no native Lotus Notes client for Linux. Wine could easily solve this problem. I talked to some of the marketing managers in IBM and most had never heard of Wine. The IBM development labs are currently starting to develop this native client. If IBM could use Wine it could save them money and sueing Wine is one thing sueing IBM is another. -- Clinersterton beademung, with all of love - RIP James Blish - Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people.
games
If you've got a safedisk1 copy protected game please contact me by private email. All safedisk1 games have a .ICD file in the root of the CD. Ivan.
Re: Menu with multi columns fix take 2
Rein Klazes wrote: +case WM_MEASUREITEM: How about an ok( ((MEASUREITEMSTRUCT*)lparam)-itemHeight 0, ... ) here? :) -flx
Re: Commercial support
IBM does very well know the existents of Wine (they even acknowledged that by themselves lately), but may very well not support it, because of inter-relation with MS. As of now (just a guess), they don't want to get into more hot water right now Would it be to the advantage of Microsoft to have Wine succeed? They have given Apple much support and at every class for the past several years the instructors have had a copy of Linux on every machine. A very good case can be made for Microsoft supporting Wine especially since the RH secure kernel came via NSA and may very well become a DOD standard. Perhaps Wine should formally contact Microsoft.
wine wiki syntax question
Hey, I have the following in my wiki page: == DONE Items == (./) Use listview instead of listbox in the drive list (./) Fix random bugs with the drives tab listview The first checkmark works, but the second checkmark and text is on the same line and behind the first one. I don't really want the checkmarks to be tabbed like they're in a list, but is there a way to have them on separate lines? -- James Hawkins
Re: Commercial support
On 5/10/05, Shachar Shemesh [EMAIL PROTECTED] wrote: And on the out come of this discussion, read the entirety of this thread and apply bays theorem and a result will soon follow. http://psych.rice.edu/online_stat/chapter5/probability.html While it's very nice of you to send me to a 10 page explanation on a topic I already know something about, I really don't have the time to read it just so I'm enlightened by some inner knowledge you think I will gain. Care to explain what it is that you are trying to say here? Please do work out the math for me. Shachar That I give up, I have voiced my humble opinion on this subject and it's time to move on. Cheers, Tom
Re: [QCAP] patch 3, Adding enumMediaType object
Rolf Kalbermatter wrote: Changelog - dlls/qcap/Makefile.in - dlls/qcap/qcap_main.h dlls/qcap/enummedia.c Add IEnumMediaType object for use by other class objects. This is taken from quartz with only minor adaptions. We should be putting these files into a static library that we can link to from quartz, qcap other DirectShow dependent DLLs. Rob
Re: Menu with multi columns fix take 2
On Tue, 10 May 2005 14:55:22 +0200, you wrote: Rein Klazes wrote: +case WM_MEASUREITEM: How about an ok( ((MEASUREITEMSTRUCT*)lparam)-itemHeight 0, ... ) here? :) Of course. I just did not want to add a complaining test case. Please commit a patch (perhaps a bit stricter then 0) Rein.
Re: Commercial support
StartCom Ltd. wrote: If they would have wanted some contact, that would have done it long time agoMore than that, if they'd like to have Windows API support on Linux, they could have done it (and still could do) much easier, than it's done now at Wine. (Like they did with Frontpage for Apache). But it could be also a revenue for MS to produce such a API-for-Linux and as current messages get out from Redmond, with some reconciliation with the Open Source community, chances may be for some interest. Mmmhh, there is Bill Hilf and Martin Taylor which are the Linux guys at MS But contacting MS should be made only after a decision (voting) of this list. gslink wrote: IBM does very well know the existents of Wine (they even acknowledged that by themselves lately), but may very well not support it, because of inter-relation with MS. As of now (just a guess), they don't want to get into more hot water right now Would it be to the advantage of Microsoft to have Wine succeed? They have given Apple much support and at every class for the past several years the instructors have had a copy of Linux on every machine. A very good case can be made for Microsoft supporting Wine especially since the RH secure kernel came via NSA and may very well become a DOD standard. Perhaps Wine should formally contact Microsoft. Now we are getting all the ideas on the table. I agree.
Re: README translations
Dimi, there are little typos in README.pt_br, see below: Dimitrie O. Paun escreveu: ChangeLog Dimitrie O. Paun [EMAIL PROTECTED] Update README translations to match the latest changes to the English README. ... Index: documentation/README.pt_br === RCS file: /var/cvs/wine/documentation/README.pt_br,v retrieving revision 1.8 diff -u -p -r1.8 README.pt_br --- documentation/README.pt_br 14 Feb 2005 11:51:05 - 1.8 +++ documentation/README.pt_br 10 May 2005 15:12:04 - @@ -21,9 +21,8 @@ nível do fonte do Wine (que contém este Execute programas conforme wine [opções] programa. Para maiores informações e resolução de problemas, leia o restante deste arquivo, -a página man do Wine (man wine), os arquivos incluídos no diretório -de documentação do fonte do Wine (veja DOCUMENTATION), e especialmente -a abundância de informação encontrada em http://www.winehq.org. +a página man do Wine (man wine), o especialmente a abundância de i +nformação encontrada em http://www.winehq.org. here the correct is: ..e especialmente a abundância de informação... 3.REQUERIMENTOS @@ -91,9 +90,6 @@ Bibliotecas de suporte opcionais: Se desejar o suporte de impressão do CUPS, por favor instale os pacotes cups e cups-devel. -Para os requesitos no caso de ter a intenção de contruir a documentação, veja -a seção DOCUMENTAÇÃO. - 4.COMPILAÇÃO No caso de escolher não usar o wineinstall, execute os comandos a seguir @@ -131,17 +127,7 @@ Não esqueça de desinstalar primeiramente Wine que possa confitante. Tente qualquer um dos comandos dpkg -r wine ou rpm -e wine ou make uninstall antes de instalar. -Se você quiser ler a documentação fornecida com a fonte do Wine, -veja a seção DOCUMENTAÇÃO. - -O Wine requer um arquivo de configuração chamado config no diretório -~/.wine. O formato deste arquivo é explicado em man wine.conf -(documentation/wine.conf.man). -O arquivo documentation/samples/config contém um exemplo de arquivo de -configuração para ser adaptado e copiado para a localização anteriormente -mencionada. - -Veja a área de suporte em http://www.winehq.org/ para mais sugestões +Veja a área de suporte em http://www.winehq.org/ para msugestões sobre a configuraçao. here msugestões should be sugestões Thanks.
New debugging tutorials
Hi, I've added the first of what will hopefully become many debugging tutorials to the wiki: http://wiki.winehq.com/DebuggingTutorials Sometimes fixing Wine can be a bit hard to get into. Hopefully these short show me guides will give people a taste for what it involves and help newbies start. Please feel free to add more! They shouldn't be too advanced (so no copy protection, WM or DCOM debugging ;) but multiple levels of difficulty is fine. Ideally they should all be based on real apps. thanks -mike
widl and #pragma pack(x)
Can it be, that widl does not work with any #pragma pack(x) statements in any header-files called from *.idl ? I have problems with mshtml.dl in the odin environment. lineno = (int)strtol(yytext, cptr, 10); if(!lineno) yyerror(Malformed '#...' line-directive; invalid linenumber); after #pragma pack(x) line. All widl-generated headers does never containn any #pragma pack(x) statement. Dietrich
Re: UT2003 Windowing Regression - Another nights effort...
I think I have reproduced the same problem with a simple testpgm... Instructions... 1. Start Visual Studio, create a default windows application 2. Comment out the code in the WM_PAINT and replace it with return 1 (important) 3. Run it... On windows you can play with the menu etc and it works. The CPU is at 100% but clicking on menu items works, and menu-exit does actually exit the app. (Menu-About causes a hang) On wine you get the infinite loop and the screen/menu never gets as far as being drawn Note:Its important to to return the 1 (or TRUE) - returning 0 works fine on both! Question... Is wine being too proactive - Perhaps in the case where the redraw is unsuccessful then wine should schedule a WM_PAINT rather than performing it? Note: UT2003 seems to just do: CreateWindowEx(AppWindow, Visible+..., ) ShowWindow(show no activate) UpdateWindow(rdw all children, updatenow) **hang** Jason
ExtTextOut() for paths
Hi.
The attached patch implements ExtTextOut() for open paths. It seems to
be working correctly for my tests but... well, the code I copied from
xrender.c is a total mess IMHO.
Calculating cell deltas and calculating the base line origin has to be
done for all kind of TrueType rendering (and most of the stuff for all
other text rendering too) so most of it should maybe be put into
ExtTextOutW() in gdi/font.c instead of duplicating it all over the
place. But I'm not sure if this would require the drv API to be changed
(which looks like it's modelled after the Win32 API on purpose) or maybe
tie gdi to x11drv.
Also from looking at the code it seems to me that the ExtTextOut()
implementation in x11drv/text.c behaves - well - different than
x11drv/xrender.c in several cases. (TA_*, rotation and break-char
handling...)
I really don't like the attached code but I don't feel like messing
around with it more so I'll just post it here - maybe someone else can
use it as a starting-point.
-flx
? gdi32.spec.def
Index: font.c
===
RCS file: /home/wine/wine/dlls/gdi/font.c,v
retrieving revision 1.10
diff -u -r1.10 font.c
--- font.c 18 Apr 2005 10:30:56 - 1.10
+++ font.c 10 May 2005 23:28:05 -
@@ -1719,35 +1719,40 @@
{
BOOL ret = FALSE;
DC * dc = DC_GetDCUpdate( hdc );
-if (dc)
+LPWSTR lpReorderedString = NULL;
+
+if (!dc) return FALSE;
+
+if (flags(ETO_NUMERICSLOCAL|ETO_NUMERICSLATIN|ETO_PDY))
+FIXME(flags ETO_NUMERICSLOCAL|ETO_NUMERICSLATIN|ETO_PDY
unimplemented\n);
+
+if( !(flags(ETO_GLYPH_INDEX|ETO_IGNORELANGUAGE)) BidiAvail count0 )
{
-if (flags(ETO_NUMERICSLOCAL|ETO_NUMERICSLATIN|ETO_PDY))
-FIXME(flags ETO_NUMERICSLOCAL|ETO_NUMERICSLATIN|ETO_PDY
unimplemented\n);
+ /* The caller did not specify that language processing was already
done. */
+ DWORD dir = WINE_GCPW_FORCE_LTR;
-if(PATH_IsPathOpen(dc-path))
-FIXME(called on an open path\n);
-else if(dc-funcs-pExtTextOut)
-{
-if( !(flags(ETO_GLYPH_INDEX|ETO_IGNORELANGUAGE)) BidiAvail
count0 )
-{
-/* The caller did not specify that language processing was
already done.
- */
-LPWSTR lpReorderedString=HeapAlloc(GetProcessHeap(), 0,
count*sizeof(WCHAR));
-
-BIDI_Reorder( str, count, GCP_REORDER,
- ((flagsETO_RTLREADING)!=0 ||
(GetTextAlign(hdc)TA_RTLREADING)!=0)?
- WINE_GCPW_FORCE_RTL:WINE_GCPW_FORCE_LTR,
- lpReorderedString, count, NULL );
-
-ret =
dc-funcs-pExtTextOut(dc-physDev,x,y,flags|ETO_IGNORELANGUAGE,
-
lprect,lpReorderedString,count,lpDx,dc-breakExtra);
-HeapFree(GetProcessHeap(), 0, lpReorderedString);
-} else
-ret =
dc-funcs-pExtTextOut(dc-physDev,x,y,flags,lprect,str,count,
- lpDx,dc-breakExtra);
-}
-GDI_ReleaseObj( hdc );
+ if((flagsETO_RTLREADING)!=0 || (GetTextAlign(hdc)TA_RTLREADING)!=0)
+ dir = WINE_GCPW_FORCE_RTL;
+
+ lpReorderedString=HeapAlloc(GetProcessHeap(), 0, count*sizeof(WCHAR));
+
+ BIDI_Reorder( str, count, GCP_REORDER, dir, lpReorderedString, count,
NULL );
+
+ flags |= ETO_IGNORELANGUAGE;
+ str = lpReorderedString;
}
+
+if(PATH_IsPathOpen(dc-path))
+ret = PATH_ExtTextOut(dc,x,y,flags,lprect,str,count,lpDx);
+else if(dc-funcs-pExtTextOut)
+ret = dc-funcs-pExtTextOut(dc-physDev,x,y,flags,lprect,str,count,
+ lpDx,dc-breakExtra);
+
+if(lpReorderedString)
+HeapFree(GetProcessHeap(), 0, lpReorderedString);
+
+GDI_ReleaseObj( hdc );
+
return ret;
}
Index: gdi_private.h
===
RCS file: /home/wine/wine/dlls/gdi/gdi_private.h,v
retrieving revision 1.25
diff -u -r1.25 gdi_private.h
--- gdi_private.h 13 Apr 2005 16:11:18 - 1.25
+++ gdi_private.h 10 May 2005 23:28:10 -
@@ -405,6 +405,8 @@
extern BOOL PATH_LineTo(DC *dc, INT x, INT y);
extern BOOL PATH_Rectangle(DC *dc, INT x1, INT y1, INT x2, INT y2);
extern BOOL PATH_Ellipse(DC *dc, INT x1, INT y1, INT x2, INT y2);
+extern BOOL PATH_ExtTextOut(DC *dc, INT x, INT y, UINT flags, const RECT
*lprec,
+LPCWSTR str, UINT count, const INT *lpDx);
extern BOOL PATH_Arc(DC *dc, INT x1, INT y1, INT x2, INT y2,
INT xStart, INT yStart, INT xEnd, INT yEnd, INT lines);
extern BOOL PATH_PolyBezierTo(DC *dc, const POINT *pt, DWORD cbCount);
Index: path.c
===
RCS file: /home/wine/wine/dlls/gdi/path.c,v
Bug 2919
Bug 2919 is beyond my area, but there is a backtrace posted. Could someone take a look and guide me on what logs to get? Thanks P.S. If you could also tell me how to determine this information for myself, it would save the list and myself a lot of time and typing. :-) Dustin
Bug 2931 (again)
Ok, the author has posted a link to the commit.. http://www.winehq.org/hypermail/wine-cvs/2004/10/0376.html Seems to be what broke it, per regression testing. I dunno if this maybe caused a bug somewhere else to show up or what, but I figure someone could look at it.. Dustin
Bug 2608 - shrinker compressed dll's cause error
This has been reported on Might and Magic 6. The file mss32.dll is compressed with a program called shrinker, when the game is installed. If another program called DeShrinker is not run on that file, MM6 refuses to run with an error. Once that is run, the game runs fine. According to the notes, there is an extra piece of information in the header in the shrinker compressed dll's called .shrink . I think this has something to do with it, but I am not totally sure. Dustin
[AppDB] - Application votes cleared
I cleared out the votes on the appdb tonight after fixing a few bugs with the voting system. The next step is to put into place a system that will expire votes that are older than some value, perhaps a year or two. I'll try to get that into place in the next week or two. Chris
Bug 2660
Bug 2660 is a regression, and the patch causing it is here: http://www.winehq.org/hypermail/wine-cvs/2004/12/0100.html Could someone take a look at the patch to see what may be wrong? Multiple (over 3) users are having this same problem on multiple versions of lotus notes..
Re: Bug 2131 - 16-bit support?
Andreas Mohr wrote: Sure, but that's a moot point, since everybody will work as much on stuff as he wants to see it progress, and that won't be too much in the Win16 case since it's of not too much interest as compared to Win32 (or probably even Win64 relatively soon). So, if john wants to play doom or duke, he either should know how to develop and contribute the code to get it working in wine, or have a friend that could do it for him? I ask because if everyone is trying to get their own stuff working (and in the process fixing other stuff that comes up along the way) who will have time to help the minority of people that want to play a classic game like duke or doom? You're already sounding like the new marketing director of some random major software company... we need FEATURES, FEATURES! Who cares about all that old crap... OOPS, didnt mean to come across that way. I was basically saying that it seems that way, as more people migrate to 64 (and away from 32), we need ot keep up with the times, and from a maintenance standpoint i think it would be much easier to maintain 1 set of code as opposed to 3. Which this has given me an idea that I will break down in the next email I send. I don't really need to tell you that this attitude is rather wrong in the Wine case, do I? No, of course not! But I see that you already have lol. Hmm, well, let me do it anyway :-) People are often migrating to Linux PRECISELY BECAUSE newer Windows versions are no alternative to them any more (old machines with insufficient performance/compatibility with newer Windows versions). And we better make sure we support their *older* Windows applications to some extent in that case. See next email Dustin
Re: shell32 - ShellDDEInit
Steven Edwards [EMAIL PROTECTED] wrote:
The ReactOS guys are tired of seeing the fixme message.
Changelog:
Implement ShellDDEInit
Index: lib/shell32/shell32_main.c
===
--- lib/shell32/shell32_main.c (revision 14808)
+++ lib/shell32/shell32_main.c (working copy)
@@ -979,13 +979,66 @@
FIXME(%lx: stub\n,dw);
}
-
+ATOM ProgmanAtom;
+DWORD hDde;
+UINT hProgmanTopic, hProgmanService, hStar, hShell, hAppProps, hFolders;
+
/*
* ShellDDEInit (SHELL32.@)
*/
-void WINAPI ShellDDEInit(BOOL start)
+void WINAPI ShellDDEInit(BOOL Start)
{
-FIXME(stub: %d\n, start);
+WCHAR wszSHELL_PROGMAN[] = {'P','R','O','G','M','A','N',0};
+WCHAR wszSHELL_TOPIC[] = {'P','r','o','g','m','a','n',0};
+WCHAR wszSHELL_SERVICE[] = {'P','r','o','g','m','a','n',0};
+WCHAR wszSHELL_STAR[] = {'*',0};
+WCHAR wszSHELL_SHELL[] = {'S','h','e','l','l',0};
+WCHAR wszSHELL_APPPROPS[] = {'A','p','p','P','r','o','p', 'e', 'r', 't',
'i', 'e', 's',0};
+WCHAR wszSHELL_FOLDERS[] = {'F','o','l','d','e','r','s',0};
+
+if (Start)
+{
+/* Create Atom */
+ProgmanAtom = GlobalAddAtomW(wszSHELL_PROGMAN);
+
+/* Initialize DDE */
+DdeInitializeW(hDde, NULL, CBF_FAIL_POKES | CBF_FAIL_ADVISES, 0L);
+
+/* Register the Strings */
+hProgmanTopic = DdeCreateStringHandleW(hDde, wszSHELL_TOPIC,
CP_WINUNICODE);
+hProgmanService = DdeCreateStringHandleW(hDde, wszSHELL_SERVICE,
CP_WINUNICODE);
+hStar = DdeCreateStringHandleW(hDde, wszSHELL_STAR, CP_WINUNICODE);
+hShell = DdeCreateStringHandleW(hDde, wszSHELL_SHELL, CP_WINUNICODE);
+hAppProps = DdeCreateStringHandleW(hDde, wszSHELL_APPPROPS,
CP_WINUNICODE);
+hFolders = DdeCreateStringHandleW(hDde, wszSHELL_FOLDERS,
CP_WINUNICODE);
+
+/* Register the Service Names */
+DdeNameService(hDde, hFolders, 0, DNS_REGISTER);
+DdeNameService(hDde, hProgmanService, 0, DNS_REGISTER);
+DdeNameService(hDde, hShell, 0, DNS_REGISTER);
+}
+else
+{
+/* Unregister the Service Names */
+DdeNameService(hDde, hFolders, 0, DNS_UNREGISTER);
+DdeNameService(hDde, hProgmanService, 0, DNS_UNREGISTER);
+DdeNameService(hDde, hShell, 0, DNS_UNREGISTER);
+
+/* Free the Handles */
+DdeFreeStringHandle(hDde, hProgmanTopic);
+DdeFreeStringHandle(hDde, hProgmanService);
+DdeFreeStringHandle(hDde, hStar);
+DdeFreeStringHandle(hDde, hShell);
+DdeFreeStringHandle(hDde, hAppProps);
+DdeFreeStringHandle(hDde, hFolders);
+
+/* Uninitialize DDE */
+DdeUninitialize(hDde);
+hDde = 0;
+
+/* Delete the Atom */
+if (ProgmanAtom) ProgmanAtom = GlobalDeleteAtom(ProgmanAtom);
+}
}
If ReactOS guys could use 'static const' for unicode strings, make global
variables visible inside of the single source file static, check whether
DDE connection is being already [de]initialed and a little bit of error
checking that would be even better :-)
--
Dmitry.
Support for binaries that were abandoned by M$, and maintenance hell?
The discussion on 16-bit support for cards.dll led me to an interesting theory. If the big name vendors are dropping support for 16-bit programs, they must be doing it for a reason, right? The only reason I can come up with is because they dont have the resources (or maybe just the desire) to maintain 2 separate trees (1 16-bit and 1 32-bit), and soon to be 3 trees including 64-bit.. We have the desire to allow any windows program to run, whether it runs in a current version of windows or not. The problem with this is that over time, dos support has faded damatically, as well as win16 support. Soon we will start writing more win64 conformance code, and less win32. Where will that leave all of the people that dont jump on the 64-bit bandwagon any time soon? flame war first shot I think we are getting to that point, from a maintenance perspective, where we should seriously consider reorganizing the project into a more hierarchal (sp?) structure, where we have some people that can take some time off from contributing 32 or 64-bit code when need be, to contribute some 16-bit code for a user who wants to use an older program. Possibly (just an idea) we should make a dedicated project page on sourceforge specifically for 16-bits. As I said, soon we will be not necessarily abandoning 32-bits, but writing more 64-bits.. Sure we have separation to keep things apart, but wine is starting to get loaded down with things that only a small minority of users need anymore.. Perhaps it is time (just another idea) to copy out the 16-bit code into it's own project? That way we can organize things more efficiently, and at the same time, reduce 1) download time of wine, and 2) compile time. Of course, we would still leave 16-bit support in the main project, but we would no longer maintain it there.. We could maintain it in wine16 /flame war first shot Comments? Suggestions? Flames??? Bring it ;-) Dustin
Docs at SourceForge
Hi folks, As most of you already noticed, the SGML docs have moved over to the CVS SourceForge: http://sourceforge.net/cvs/?group_id=6241 They clearly did not belong in the tree, and we decided at WineConf05 to move them out of there. So we did. I have renamed the files for a more uniform naming, and dropped couple of unused files in the process. We still need to change WineHQ's scripts to point them to the new location. Help with this would be appreciated. I'll be managing that tree for now (unless Alexandre wants to do it :)). Please send your patches as you usually do to [EMAIL PROTECTED], but make sure to prefix the subject with '[WINEDOCS]' so I can more easily spot them. Discussions should take place on wine-devel@winehq.org as per normal. The new repository is set up with translations in mind, so hopefully will be able to handle them better in the future. I'll be working with Francois to integrate the French translation shortly. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Getting rid of LOCAL_ exports
From a cursory look at the problem, it seems we can turn things
upside down. Right now LOCAL_*() functions (Wine specific) are
equivalent to the Local*16() functions (Windows exports), with
the exception that they take a selector as first argument
(which makes them more general). As a result, Local*16() functions
are implemented on top of the LOCAL_*() ones.
This is only half of the story. In fact, the Local*16() functions
do take the segment as input, but in a more awkward manner:
as the value of the DS register. So we can actually implement
the LOCAL_*() functions on top of the Local*16() ones by messing
with the DS register. Doing so would hopefully get rid of the
LOCAL_*() exports from kernel.
I've taken a stab (prototype level) at the LOCAL_Alloc() function
(patch included below). Would such an approach be acceptable?
Index: include/local.h
===
RCS file: /var/cvs/wine/include/local.h,v
retrieving revision 1.6
diff -u -p -r1.6 local.h
--- include/local.h 28 Aug 2003 21:43:35 - 1.6
+++ include/local.h 10 May 2005 18:20:03 -
@@ -23,12 +23,22 @@
#include windef.h
#include wine/windef16.h
+#include stackframe.h
/* These function are equivalent to the Local* API functions, */
/* excepted that they need DS as the first parameter. This*/
/* allows managing several heaps from the emulation library. */
+static inline HLOCAL16 LOCAL_Alloc( HANDLE16 ds, UINT16 flags, WORD
size )
+{
+HANDLE16 oldDS = CURRENT_DS;
+HLOCAL16 ret;
+
+CURRENT_DS = ds;
+ret = LocalAlloc16 (flags, size);
+CURRENT_DS = oldDS;
+return ret;
+}
-extern HLOCAL16 LOCAL_Alloc( HANDLE16 ds, UINT16 flags, WORD size );
extern HLOCAL16 LOCAL_ReAlloc( HANDLE16 ds, HLOCAL16 handle,
WORD size, UINT16 flags );
extern HLOCAL16 LOCAL_Free( HANDLE16 ds, HLOCAL16 handle );
Index: dlls/kernel/kernel32.spec
===
RCS file: /var/cvs/wine/dlls/kernel/kernel32.spec,v
retrieving revision 1.148
diff -u -p -r1.148 kernel32.spec
--- dlls/kernel/kernel32.spec 10 May 2005 15:22:10 - 1.148
+++ dlls/kernel/kernel32.spec 10 May 2005 18:22:10 -
@@ -1167,7 +1167,6 @@
# Wine dll separation hacks, these will go away, don't use them
#
@ cdecl DOSMEM_AllocSelector(long)
-@ cdecl LOCAL_Alloc(long long long)
@ cdecl LOCAL_Compact(long long long)
@ cdecl LOCAL_CountFree(long)
@ cdecl LOCAL_Free(long long)
Index: dlls/kernel/local16.c
===
RCS file: /var/cvs/wine/dlls/kernel/local16.c,v
retrieving revision 1.10
diff -u -p -r1.10 local16.c
--- dlls/kernel/local16.c 24 Mar 2005 21:01:38 - 1.10
+++ dlls/kernel/local16.c 10 May 2005 17:56:15 -
@@ -1150,15 +1150,13 @@ HLOCAL16 LOCAL_Free( HANDLE16 ds, HLOCAL
/***
- * LOCAL_Alloc
- *
- * Implementation of LocalAlloc().
- *
+ * LocalAlloc (KERNEL.5)
*/
-HLOCAL16 LOCAL_Alloc( HANDLE16 ds, WORD flags, WORD size )
+HLOCAL16 WINAPI LocalAlloc16( UINT16 flags, WORD size )
{
+HANDLE16 ds = CURRENT_DS;
+HLOCAL16 handle = 0;
char *ptr;
-HLOCAL16 handle;
TRACE(%04x %d ds=%04x\n, flags, size, ds );
@@ -1171,7 +1169,7 @@ HLOCAL16 LOCAL_Alloc( HANDLE16 ds, WORD
if(size)
{
if (!(hmem = LOCAL_GetBlock( ds, size + MOVEABLE_PREFIX, flags )))
- return 0;
+ goto exit;
}
else /* We just need to allocate a discarded handle */
hmem = 0;
@@ -1180,7 +1178,7 @@ HLOCAL16 LOCAL_Alloc( HANDLE16 ds, WORD
WARN(Couldn't get handle.\n);
if(hmem)
LOCAL_FreeArena( ds, ARENA_HEADER(hmem) );
- return 0;
+ goto exit;
}
ptr = MapSL( MAKESEGPTR( ds, 0 ) );
plhe = (LOCALHANDLEENTRY *)(ptr + handle);
@@ -1199,10 +1197,11 @@ HLOCAL16 LOCAL_Alloc( HANDLE16 ds, WORD
}
else /* FIXED */
{
- if(!size)
- return 0;
- handle = LOCAL_GetBlock( ds, size, flags );
+ if(size) handle = LOCAL_GetBlock( ds, size, flags );
}
+
+exit:
+CURRENT_STACK16-ecx = handle; /* must be returned in cx too */
return handle;
}
@@ -1595,17 +1594,6 @@ HLOCAL16 LOCAL_Handle( HANDLE16 ds, WORD
/***
- * LocalAlloc (KERNEL.5)
- */
-HLOCAL16 WINAPI LocalAlloc16( UINT16 flags, WORD size )
-{
-HLOCAL16 ret = LOCAL_Alloc( CURRENT_DS, flags, size );
-CURRENT_STACK16-ecx = ret; /* must be returned in cx too */
-return ret;
-}
-
-
-/***
* LocalReAlloc (KERNEL.6)
*/
HLOCAL16 WINAPI LocalReAlloc16( HLOCAL16 handle, WORD size, UINT16
flags )
--
Dimi
