Re: Wine packaging - part 2 - what RPM/DEBs do
You could also view the global config as the values with which to initialise the local config when a user first uses wine. You might also want to have a process that would refresh those values should it be necessary to change something for all users, but that presupposes multi user, and as I recall someone suggested that that should 1.1. Alexandre Julliard <[EMAIL PROTECTED]> on 26-10-2000 10:29:21 PM To: Jeremy White <[EMAIL PROTECTED]> cc: Marcus Meissner <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (bcc: David Goodenough/DGA/GB) Subject: Re: Wine packaging - part 2 - what RPM/DEBs do Jeremy White <[EMAIL PROTECTED]> writes: > Hmm. I had not seriously considered simply adding > an 'inherit' ability. A cursory look at the > .winerc suggests, for most things, it would be pretty easy. > It would make winecfg harder (or much > harder to do well, IMO). It would also make it much harder for users to figure out what's going wrong (not to mention that they'll have to post both their config and the global one to get any useful support). > I think if we simplify the presentation > of Wine, and discuss *only* the ~/.wine/config > file, we'd make life easier for most Wine users. Agreed; Wine should only try to load the user config file. If someone really wants a global config, it is always possible to make the user config a symlink to some central file. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Forwarded Message From Claus Fischer re Packaging
Alexandre Julliard wrote: > David Elliott <[EMAIL PROTECTED]> writes: > > > I didn't mean switching between different compiled versions of wine, I meant > > just switching config files and registry hives. > > That's exactly what WINEPREFIX is for. It switches to a different set > of config file/registry files/server socket. > Well then, I stand corrected, I guess I'll use that! -Dave
New Windows API functions
Changelog:
* Added basic working stubs of new Windows 2000 API functions.
This patch provides working stubs for some of the new Windows 2000 API calls
as follows:
Terminal Server functions:
* RegOpenCurrentUser has been implemented by opening HKEY_CURRENT_USER Both
dlls/advapi32/registry.c and memory/registry.c have been changed. I used ""
as the path to open under HKEY_CURRENT_USER, should that be "\\" or is ""
okay?
* GetSystemWindowsDirectory[AW] calls GetWindowsDirectory[AW]. I chose to
stub out the function rather than forward because it may be usefull when
packaging wine for this to be a different directory, see MSDN documentation
on this function for details.
* ProcessIdToSessionId returns 0 in all cases per MSDN docs.
CriticalSection:
* InitializeCriticalSectionAndSpinCount - Calls
RtlInitializeCriticalSectionAndSpinCount function like
InitializeCriticalSection. Returns TRUE if no error occured, false if an
error occured. Since no errors can possibly occur at this time it will
always return TRUE.
* SetCriticalSectionSpinCount - Sets crit->SpinCount
* RtlInitializeCriticalSectionAndSpinCount - Sets crit->SpinCount then calls
RtlInitializeCriticalSection.
The above functions are related to SMP. On a uniprocessor windows sytem,
the spincount is always zero. For now these functions will actually set the
spincount, but since it's not used by anything in the wine core, they
basically do nothing. They print FIXME's when used with spincounts other
than 0.
User32:
* GetClipboardSequenceNumber - This is a stub returning 0 per MSDN docs.
This deserves a real implementation at some point, but is not a
high-priority thing.
* AllowSetForegroundWindow - This is a stub returning TRUE. This function
relates to the changes in focus behavior for Win98/win2k. The new focus
behavior requires certain conditions to be met for a process to grab the
foreground focus with SetForegroundWindow. This function allows a program
that is running in the foreground to give another process the ability to set
the foreground window like would have been allowed in older versions of
windows.
* LockSetForegroundWindow - Ditto except this function disallows all other
programs to grab the foreground with SetForegroundWindow until the user
switches away from the window for the program that called this function.
Other
* _ultow - Added @ stub entry to ntdll.spec
* strtol - Added @ cdecl entry using libc's strtol to ntdll.spec
-Dave
Index: dlls/advapi32/advapi32.spec
===
RCS file: /home/wine/wine/dlls/advapi32/advapi32.spec,v
retrieving revision 1.12
diff -u -r1.12 advapi32.spec
--- dlls/advapi32/advapi32.spec 2000/10/24 01:39:29 1.12
+++ dlls/advapi32/advapi32.spec 2000/10/27 10:13:55
@@ -191,6 +191,7 @@
@ stdcall RegLoadKeyA(long str str) RegLoadKeyA
@ stdcall RegLoadKeyW(long wstr wstr) RegLoadKeyW
@ stdcall RegNotifyChangeKeyValue(long long long long long) RegNotifyChangeKeyValue
+@ stdcall RegOpenCurrentUser(long ptr) RegOpenCurrentUser
@ stdcall RegOpenKeyA(long str ptr) RegOpenKeyA
@ stdcall RegOpenKeyExA(long str long long ptr) RegOpenKeyExA
@ stdcall RegOpenKeyExW(long wstr long long ptr) RegOpenKeyExW
Index: dlls/advapi32/registry.c
===
RCS file: /home/wine/wine/dlls/advapi32/registry.c,v
retrieving revision 1.15
diff -u -r1.15 registry.c
--- dlls/advapi32/registry.c2000/10/15 00:40:25 1.15
+++ dlls/advapi32/registry.c2000/10/27 10:13:58
@@ -248,6 +248,19 @@
}
+/**
+ * RegOpenCurrentUser [ADVAPI32]
+ * FIXME: This function is supposed to retrieve a handle to the
+ * HKEY_CURRENT_USER for the user the current thread is impersonating.
+ * Since Wine does not currently allow threads to impersonate other users,
+ * this stub should work fine.
+ */
+DWORD WINAPI RegOpenCurrentUser( REGSAM access, PHKEY retkey )
+{
+return RegOpenKeyExA( HKEY_CURRENT_USER, "", 0, access, retkey );
+}
+
+
/**
* RegEnumKeyExW [ADVAPI32.139]
Index: dlls/kernel/kernel32.spec
===
RCS file: /home/wine/wine/dlls/kernel/kernel32.spec,v
retrieving revision 1.14
diff -u -r1.14 kernel32.spec
--- dlls/kernel/kernel32.spec 2000/10/23 21:39:39 1.14
+++ dlls/kernel/kernel32.spec 2000/10/27 10:14:02
@@ -928,3 +928,10 @@
#1599 wrong ordinal (249 in Win32s's W32SCOMB.DLL) !
1599 stdcall Get16DLLAddress(long str) Get16DLLAddress
+
+# Windows 2000, Terminal Server 4.0 SP4 functions
+@ stdcall GetSystemWindowsDirectoryA(ptr long) GetSystemWindowsDirectoryA
+@ stdcall GetSystemWindowsDirectoryW(ptr long) GetSystemWindowsDirectoryW
+@ stdcall InitializeCriticalSectionAndSpinCount(ptr long)
+InitializeCriticalSectionAndSpinCount
+@ stdcall SetCriticalS
Netscape 4.7 painting problem is a font problem
Hi All, i've tracked down the source of the Netscape 4.7 painting problem i've been looking at... but i'm not sure how to fix it. The problem is that the stock varible font as fetched by GetStockObject(STOCK_ANSI_VAR_FONT) changes. Initially it is MS Sans Serif, but later changes to helvetica. Netscape seems to like helvetica better :-/ The patch below makes the problem go away, but doesn't fix the source of the problem... i'll investigate more tommorrow. Mike >On Fri, 20 Oct 2000, Mike McCormack wrote: > > When netscape first loads, it has problems painting all types of > controls (buttons, combos, etc) and some text on web pages. As more > pages are loaded, the problems disappear... ie. things that were > previously were not drawn are drawn correctly. > -- mailto:[EMAIL PROTECTED] ph +61 2 9427 2196 __ Get your own free web email at http://www.looksmart.com.au LookSmart Australia patch30 z
IBM HPB patches
I have now divided up the fixes into the four classes, and discarded the ones that are of no relevance. This leaves about 30 patches, a few of which really should be grouped together. The fixes come into a number of broad headings:- 1) New function 2) Minor fixes, particularly they seem to have hit a number of NULL pointer/handle problems and provide fixes to stop this causing traps 3) A new mode of operation which they called unmanaged. This seems to make ALL windows unmanaged, including the dialogs. I am not quite sure why they did this, but they did. 4) A few I can not yet understand or give a purpose to. Of the new function there is:-- 1) Support for BS_MULTILINE in controls/button.c 2) 24 bit graphics support in graphics/x11drv/dib.c 3) In dlls/shell32/shlfileop.c added dialogs to ask for confirmation of deletes when flags set. Add SHELL_IsFolderA, SHELL_CopyFolderA, and put real code into SHFileOperationA 4) Changes to graphics/x11drv/xfont.c to change the maximum font size (from 1000 to 2000), to add a weight of "demi bold" (including the space), to define serif, cursive, monospace, and fantasy, to ignore fonts with no weights or width name, to precreate bold and italic fonts, a change to what happens when looking for fonts with a lower resolution, addition of W3C Chancery font, change when building font metrics to support fonts [a 0 b c] in weight field of ltd which caused one of their programs to display a strange logo if missing. In the minor fixes class:- 1) Fix to GetFullNamePathA( ) to return the value in lower case (no explanation given as to why) 2) Check for a NULL value returned in objects/enhmatafile.c 3) Change to windows/x11drv/event.c to show child windows at OnSetFofus - seen as a workaround for an unspecified problem 4) In objects/gdi.obj change to put out a message when GDI resources run out (a message box) and exiting preemptoraly, rather than just returning 0. 5) in miscemu/main.c changes to add signal handlers to clean up failed programs. 6) Change in windows/mdi.c to check child and frame for NULL before trying to use things pointed to by them 7) Changes to control/menu.c to check for NULL popupmenus before trying to use them. 8) Safety check on This->sMyPath before being it in dlls/shell32/shlfolder.c 9) changes to controls/static.c to handle case of no text, and to handle SS_CENTREIMAGE. 10) Change to dlls/comctl32/tooltops.c for the case of text == "" (rather than NULL). 11) Changes to dlls/comctl32/trackbar.c to do some calculations as doubles rather than ints. Also fix to support TBS_AUTOTICKS. 12) Change to dlls/comctl32/updown.c at a labled FIXME, which claims that the MSDN specified value for infoPtr->MinVal should be 100 not 0, and for MaxVal should be 0 not 100. Changes for unmanged mode:- 1) In windows/x11drv/event.c change condition for changing focus 2) Changes in control/menu.c to cope with menus in unmanaged dialogs 3) support in windows/message.c and nonclient.c and misc/options.h 4) Changes in windows/win.c to support unmanaged windows In the non-understood category:- 1) In dlls/commdlg/filedlg.c, filedlg95.c and filedlgbrowser.c changes to the behaviour when a folder is selected. 2) Changes in dlls/comctl32/header.c, listview.c and include/listview.h. These talk about adding Drag and Drop support, some of this seems to be present in the current code, but not all. 3) Added code to misc/options.h to RaiseException at EnterCriticalSection. I can only presume they were having problems with CriticalSections and this was a debugging aid, but it is there in there full release. 4) In dlls/shell32/pidl.c they change from using CSIDL_DESKTOPDIRECTORY to CSIDL_DESKTOP. Why is unclear. 5) In dlls/comctl32/propsheet.c there are changes to add support for PSH_WIZARD97, whatever that might be. I get the impression this might add multipage wizards, but I am not familiar enough with what a PSH_WIZARD can do to comment. 6) In dlls/shell32/shellpath.c a variety of changes. Some to PathIsRootA, with special changes for references to "My Computer" and to explicit unix paths. Also added support for CSIDL_DESKTOP, but does nothing but return TRUE which is apparently all that is needed. This is presumably tied in with 4 above. 7) Some changes in windows/X11drv/wnd.c to stop X_QueryTree: BadWindow problems. One of these is fairly straight forward, but the other is in an area that has been changed substancially since and I am not clear whether it is still necessary. Now the next question is, for those that I have renumbered and apply and compile cleanly, how do you want them. Do you want them one at a time, so they can be discussed individually, or for instance in the case of the safety checks as a single grouped block. For those in the last class I would also value any input anyone might have on the need/usefulness of these fixes. I can send you the individual fixes, but remember they are quite old when you come to look at them. Some I have relocated to 2000
unsubscribe qwerty
Re: IBM HPB patches
Can you send me the shell32 and filedlg related parts (or just everything)? I would like to look at least over the code since I guess from your descriptions there might be some application specific hacks in it. Where to get the whole patch on the web? Thanks Juergen
Re: IShellBrowser window ID
Hi! I had a look at geralds patch and he moving the code whats initializing the view after sending some messages. This should be ok since is not a problem to initialize the shellview as late as possible to allow other programs to eg. reorder controls or to resize the hidden listview. The shellview gets the dimensions from the hidden listview on creation. If the shellview is created later it should get the right dimensions. Is there still a problem left? Is there a downloadable program? juergen
Re: Fix for selected bitmap menu items
Hi, On Fri, 27 Oct 2000, Dmitry Timoshkov wrote: > Hello. > > Changelog: > Make bitmap menu items look like in windows when selected, > i.e. hilited and inverted. This patch does not seem right to me. I base this on my observations of the behavior of the grafmenu, a smaple program of the Petzold 95. This program creates a menu containing black and white bitmaps and here is what it looks like: * in Win95 - the normal display is black text on the regular gray background - when an item is selected its background becomes white, the text stays black - except for the checkboxes which become white on the regular gray background * in win98 - same as Win95 when the window is active and the mouse is not over the menu bar - if the window is inactive then the black parts become dark gray, i.e. it looks the same as if we had a regular menu - when the mouse is over a menu bar item, there's a raised border drawn around the bitmap (even if the window is inactive) - when a menubar item is selected, there is a sunken border drwan around it and, unlike in Win95, the background remains grey - when a menu item is selected, it is highlighted like any other, i.e. we have the dark blue background. But the bitmap is indeed displayed kind of inverted. I get dark blue on white. And I also note that the size of the menu item is calculated so that there is a 1 pixel dark blue border above and below the bitmap. This is pretty complex and differs from what we get in Wine (with or without your patch). I believe one of the problems in Wine lies in the calculation of the item size: the sunken/raised border is overwritten by the bitmap so that we don't see it. Then there's all the color and Win95 vs. Win98 aspects. You can have a look at the URL below, it contains a screenshot of grafmenu in Win95. I'll try to add other screenshots for Win98. http://fgouget.free.fr/wine/PrgWin95/Chap10.shtml#grafmenu -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Broadcast message : fin du monde dans cinq minutes, repentez vous !
RE: Mail sent to wine-devel
> Your mail to 'wine-devel' with the subject: > > RFC: Logical to device translation layer > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Message body too long (>40k) > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. Intresting but a little irritating feature of the new mailing list. I understand it is because some people post to long debug logs on the list. But it would be nice if people that are regular posters to the list be removed from the limit or at least have a larger limit. PS. If anybody cares my mail included a 85k large patch plus a quite long message. PPS. Hmm. Should I wait or should I post it without the patch, in the meantime. OK, I will wait, but if anybody really want to read "RFC: Logical to device translation layer" as soon as possible please mail me in private.
RFC: Logical to device translation layer
After the discussion triggered by Mark Dufour's attempt
to optimize X11DRV_LineTo, I sat down I tried to think
through what various people had said and try to find
a solution that would satisfy the worries of different
people including myself. :-)
This resulted in the following solution to the problem
of optimizing the GDI functions that I have implemented
the _infrastructure_ for. A patch that does this is
attached in order to try to move the discussion from
teoretical worries and problems down to the worries and
problems of the real world.
So what I'm I trying to do?
First an observation: The current mapping, to use a
common name for offsets, scale factors, rotations
or other kind of transforms, seldom changes. In fact
it can only change if the application calls one of
the following functions.
SetMapMode
{Set,Modify}WorldTransform
{Set,Offset,Scale}{Viewport,Window}{Ext,Org}Ex
In Wine's implementation, all of these functions
will eventually call the function DC_UpdateXforms
in object/dc.c before returning.
Since all calls to the device driver (X11, printer etc)
goes through the the dc->funcs (DC_FUNCTIONS) jump table,
we could check how advanced the current mapping and
change the jump table accordingly.
This is pretty obvious. As Huw D M Davies said to me
"I know you were going to suggest that". :-)
However if done in a bad way this will lead to a lot
of code duplication and make maintaince more difficult
as Ulrich Weigand pointed out.
So I sat down and though about it some more.
One of the first things I observed is that there are two
different kinds of device drivers. One that works in logical
coordinates since the underlying "system" can or must
use them and the kind the have no real concept of logical
coordinates and always converts them to device coordinates.
The important ones that works with logical coordinates is
the {,enh}metafile drivers and among the important ones that
works with device coordinates is primarily the X11 driver.
This realization led to the idea that we really should have
two DC_FUNCTIONS jump tables of that takes logical coordinates
and one that takes device coordinates.
Before anybody points it out, I will point out the fact that
many functions are coordinate system independent and that we in
that case should split up DC_FUNCTIONS is two different structures.
This is probably true but this is an almost completly ortogonal
problem, that is easy to solve, so I will not discuss it further.
It doesn't really effect performance, it mainly effects maintainance.
So we will end up with drivers that have device jump table
mainly empty (metafile) and drivers that will have the logical
jump table mainly empty (X11).
OK, so how are we going to call everything from the device independent
parts. We don't want to the device independ layer to work with
device coordinates that will probably be painful.
So we have the device indendent layer that wants to use logical
coordinates and some device drivers (X11) that wishes to use
device coordinates. That doesn't really mix well together does it?
The answer is a logical to device translation layer.
Will that not be expensive permformancewise and hard to
maintain you ask? No, not at all. See the attached patch.
In fact it will optimize the most important path, the
constant scaling zero offset case, the best. That is, the case
that applications that really cares about performance are
likely to use.
It might be a little hard to see what the patch does so I will
try to explain.
There are 4 different kinds of translations.
1. Full world transform (implemented in graphics/log2dev.c)
2. Scaling (implemented in graphics/scl2dev.c)
3. Offsetting (implemented in graphics/off2dev.c)
4. Nothing (not implemented anywhere since it is not needed)
Each device driver have two DC_FUNCTIONS jump tables, or for logical
coordinates and one for device coordinates.
When we register even device driver we use these 2 jump tables
to generate 4 jump tables for the 4 cases above that uses that
the translation function if needed. The jump table for case 4
is just a direct call to device driver table for device
coordinates so _no_ translation is performed at all.
When the mapping changes (DC_UpdateXforms
in object/dc.c is eventually called) we choose
which of the 4 jump tables which should be used.
Note that this patch currently only implement the
infrastructure for this. If and when applied, however
we can begin the real work of making Wine run faster.
However we have to be really careful when we do this,
there are a few dragons lurking in the forest of
ignorance.
In case 4 no translation is needed, so the translation layer
is not called at all. This which mean that we have to be
really careful _where_ optimizing if-nothing-visible-needs-to-be-
drawn tests and swap-the-parameters-when-"left"-greater-than-
"right" test are performed.
There are three places when such tests can be placed.
(1) Logical (device independent) layer
(2) Logical to Device laye
RE: Mail sent to wine-devel
On Fri, 27 Oct 2000, Patrik Stridvall wrote: > > Message body too long (>40k) > > > > Either the message will get posted to the list, or you will receive > > notification of the moderator's decision. > > Intresting but a little irritating feature of the new mailing list. > > I understand it is because some people post to long debug logs > on the list. But it would be nice if people that are regular > posters to the list be removed from the limit or at least have > a larger limit. > > PS. If anybody cares my mail included a 85k large patch > plus a quite long message. > > PPS. Hmm. Should I wait or should I post it without the patch, > in the meantime. OK, I will wait, but if anybody really want > to read "RFC: Logical to device translation layer" as soon > as possible please mail me in private. Okay, I've approved, but it's on your own peril. There is no limit to the size of postings to wine-patches, but wine-devel, on the other hand, runs with a 40K limit. This was discussed briefly by web-admin, and nobody there saw a problem with safety limits on the non-patches lists. Do anyone else around wish for us to increase the wine-devel limit? Even our low-bandwidth subscribers?
RE: Mail sent to wine-devel
> Okay, I've approved, but it's on your own peril. Oh well < 100kb => < 20s with a 56k modem. I don't expect anybody to be _that_ pissed off. At least I hope not. :-) > There is no > limit to the > size of postings to wine-patches, but wine-devel, on the > other hand, runs > with a 40K limit. This was discussed briefly by web-admin, and nobody > there saw a problem with safety limits on the non-patches > lists. It is not normally a problem. This RFC patch just happend to be unusually big because of it is quite a lot of cut and pasting to illustrate an idea. I don't know. What does other people say? Should large RFC patches be put on a webserver (WineHQ?) or is it OK to post them on the list? > Do anyone > else around wish for us to increase the wine-devel limit? Even our > low-bandwidth subscribers? I do not wish to increase it for casual posters but people that post a lot do not post large attachment without a good reason. Sure I _could_ have, by misstake, attached one (or more) of 5Mb+ debug logs that was in the same directory so we probably should have some limit. That probably would have pissed people off. :-)
Preferred way to get all 'recent' code
Sorry if this is covered somewhere and I just missed it. What is the preferred way to get wine's source tree. Is it acceptable to cvs login and cvs checkout all of wine, or is there some other more preferrable way? Thanks. George __ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/
Header files that conflict with UNIX headers
Hi all, I am starting to work on CRTDLL implementing it on top of Windows calls instead of UNIX. As I understand it, Windows executables definitely need a working CRTDLL as forwarding things like fopen to UNIX would not give the desired behavior. Are Winelib programs also supposed to use the wine CRTDLL? If so then it's necessary to provide headers like stdlib.h and math.h to Winelib programs and to link the winelib programs against the wine crtdll instead of the native libc. The problem I see with this is that it's feasible for a winelib program to want to use the native libc instead of CRTDLL. Using the native libc is the current behavior AFAIK. It is not possible to put the headers into include/ because other wine code will use them instead of the UNIX headers. Should they be placed in something like include/wincrt? What directory should they be installed to? How should we allow wine sourcecode to choose the use of the native files or the provided files? Currently things like FILE are defined as CRTDLL_FILE directly in the source file instead of a seperate header. It will be desirable to allow the crtdll source to include both the UNIX libc headers and parts of the Wine crtdll headers. How should the wine crtdll headers look? Should they use some preprocessor magic to allow them to be used by winelib programs (e.g. with names like "FILE") and also by the wine source itself (e.g. with names like "CRTDLL_FILE"). For now I am not providing any headers, just implementing the functions, but I will if someone can tell me how it should be done. As far as the CRTDLL implementation goes, I am currently implementing CRTDLL with all of the functions and structures prefixed with CRTDLL_ (following the current trend). I am calling native libc functions when it makes sense to do so (like most math functions). I vaguely remember this being brought up before and the consensus being something along the lines of libc functions should be used when available and we can always create and link against another UNIX library to implement functions that are not supported on all libcs rather than clutter the code with tons of #ifdefs. I also vaguely remember that using the libc functions is preferred because they are generally the best implementation of the function. Obviously this does not hold true for things like fopen and friends, but for things like math functions this should be fine. Currently the crtdll.spec directly uses several libc functions, which I also do not see any reason to change. If the function is implemented correctly by the libc then use it. If wine or this crtdll code is to be ported to a platform that does not have a libc, the aforementioned creation of another library should be done to implement the function. It should be acceptable for the CRTDLL to link against this library to provide the implementation of the functions. One notable concern was the handling of varargs functions. I believe that the CRTDLL code should hanlde varargs in the style of the OS it is running on and that winebuild should create a thunk layer for varargs functions on platforms that require it. CRTDLL should not try to handle Windows format varargs in its code. From the looks of it, it appears this is how things are currently done, although Linux does not require this layer as its libc's varargs handling is the same as Windows just like the other calling conventions. So, does my reasoning sound okay? What should be done with the headers? -Dave
Re: Preferred way to get all 'recent' code
On Fri, Oct 27, 2000 at 06:14:35PM -0700, George Boutwell wrote: > Sorry if this is covered somewhere and I just missed > it. What is the preferred way to get wine's source > tree. Is it acceptable to cvs login and cvs checkout > all of wine, or is there some other more preferrable > way? Yes, CVS is the most accepted one. If you're an end-user, you might want to stick with normal releases. But even for end-users CVS is not too bad ;) Andreas Mohr
WEP (Windows Entertaiment Pack)
This is an old, old package of (very) simplistic games that I've found on one of my old HDs. It contains games such as "Jezz Ball", "Maxwell", "Ski", "Warhead", etc. Most of the stuff in there seems to work, which the notable exception of two VB games. There were a few display glitches, maily caused by our handling of the managed mode. The most obvious manifested itself in a few cases (maybe the game was using a dialog as its main window???) where the window will get positioned in the left-top corner such as the left and top decorations will be off the screen. In other words, the window got positioned such as the top-left corner of the client rectangle would coincide with the top-left corner of the screen. If anyone feels like looking into this, I'm game. Anyway, despite their simplicity, this shows good progress, so I figured I'll share. -- Dimi.
Re: GetProcAddress
On Sat, 28 Oct 2000 [EMAIL PROTECTED] wrote: > I am trying to make a winelib rundll32, but I can not get GetProcAddress > to return anything but (nil). I must be doing something even stupider > than the stupid errors I have already fixed, but I can't see it. Maybe > somebody who is really bored could tell me the error of my > ways. Wine-20001026 with wine_win2k.diff, wininet.diff, Rein's little > timezone patch, and Marcus' OleLoadFromStream and itemmoniker from > wine-patches. Apart from that your string handling is somewhat clumsy and bug-ridden (one of these bugs are likely to leave the space character in the string you pass to GetProcAddress), I don't see any other obvious misuse of GetProcAddress here. Perhaps you could also look at regapi, which already contains a regsrv-like function (registerDLL -> doRegisterDLL())?
