Switching to winecfg
As winecfg gets better and better I think it's time to consider making
it actually change the config file. I made a patch for it, but it's a
work in progress, and not ready for general use. I don't expect you to
commit it, so I sent it here for discussion.
I don't think that this needs a complex migration process, all we need
to do is save the wine config registry to $WINEPREFIX/config. If people
want their config file back, wine can skip saving the configuration if
it wasn't modified. This will allow comments to persist in the config
file. Anyway, regedit is better than editing a config file.
In writing this patch I came across some strange stuff in
server/registry.c. What's the point of all the save level stuff?
current_level is only set once to 1, on initialization, and save_level
depends on whether registry branches should be saved only when modified
(can anyone think of a reason to disable that feature?). Can't the
KEY_DIRTY bit be used instead of this level stuff? Also update_level
seems to be dead code, not called from anywhere.
Please tell me what you think about the patch.
--
Crestez Leonard <[EMAIL PROTECTED]>
Index: dlls/dsound/dsound_main.c
===
RCS file: /home/wine/wine/dlls/dsound/dsound_main.c,v
retrieving revision 1.110
diff -u -r1.110 dsound_main.c
--- dlls/dsound/dsound_main.c 7 Oct 2004 03:06:50 - 1.110
+++ dlls/dsound/dsound_main.c 8 Jan 2005 03:39:26 -
@@ -152,7 +152,7 @@
buffer[MAX_PATH]='\0';
if (RegCreateKeyExA( HKEY_LOCAL_MACHINE, "Software\\Wine\\Wine\\Config\\dsound", 0, NULL,
- REG_OPTION_VOLATILE, KEY_ALL_ACCESS, NULL, &hkey, NULL ))
+ REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, &hkey, NULL ))
{
ERR("Cannot create config registry key\n" );
ExitProcess(1);
Index: dlls/x11drv/x11drv_main.c
===
RCS file: /home/wine/wine/dlls/x11drv/x11drv_main.c,v
retrieving revision 1.96
diff -u -r1.96 x11drv_main.c
--- dlls/x11drv/x11drv_main.c 8 Dec 2004 18:06:15 - 1.96
+++ dlls/x11drv/x11drv_main.c 8 Jan 2005 03:39:30 -
@@ -253,7 +253,7 @@
DWORD len;
if (RegCreateKeyExA( HKEY_LOCAL_MACHINE, "Software\\Wine\\Wine\\Config\\x11drv", 0, NULL,
- REG_OPTION_VOLATILE, KEY_ALL_ACCESS, NULL, &hkey, NULL ))
+ REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, NULL, &hkey, NULL ))
{
ERR("Cannot create config registry key\n" );
ExitProcess(1);
Index: programs/winecfg/winecfg.h
===
RCS file: /home/wine/wine/programs/winecfg/winecfg.h,v
retrieving revision 1.20
diff -u -r1.20 winecfg.h
--- programs/winecfg/winecfg.h 23 Nov 2004 13:50:23 - 1.20
+++ programs/winecfg/winecfg.h 8 Jan 2005 03:39:39 -
@@ -126,6 +126,6 @@
SetWindowText(GetDlgItem(dialog, id), text);
}
-#define WINE_KEY_ROOT "Software\\Wine\\Testing\\Config"
+#define WINE_KEY_ROOT "Software\\Wine\\Wine\\Config"
#endif
Index: server/registry.c
===
RCS file: /home/wine/wine/server/registry.c,v
retrieving revision 1.61
diff -u -r1.61 registry.c
--- server/registry.c 30 Nov 2004 21:38:57 - 1.61
+++ server/registry.c 8 Jan 2005 03:39:40 -
@@ -104,7 +104,7 @@
/* keys saving level */
/* current_level is the level that is put into all newly created or modified keys */
/* saving_level is the minimum level that a key needs in order to get saved */
-static int current_level;
+static int current_level = 1;
static int saving_level;
static struct timeval next_save_time; /* absolute time of next periodic save */
@@ -118,7 +118,7 @@
char*path;
};
-#define MAX_SAVE_BRANCH_INFO 3
+#define MAX_SAVE_BRANCH_INFO 4
static int save_branch_count;
static struct save_branch_info save_branch_info[MAX_SAVE_BRANCH_INFO];
@@ -236,7 +236,14 @@
{
int i;
+/* Don't save volatile keys. */
if (key->flags & KEY_VOLATILE) return;
+/* Don't save this if it's a different save brach. */
+for (i = 0; i < save_branch_count; ++i) {
+if (key == save_branch_info[i].key && key != base) {
+return;
+}
+}
/* save key if it has the proper level, and has either some values or no subkeys */
/* keys with no values but subkeys are saved implicitly by saving the subkeys */
if ((key->level >= saving_level) && ((key->last_value >= 0) || (key->last_subkey == -1)))
@@ -1505,7 +1512,7 @@
NULL, 0, time(NULL), &dummy )))
fatal_error( "could not create Config registry key\n" );
-key->flags |= KEY_VOLATILE;
+/* key->flags |= KEY_VOLATILE; */
load_init_registry_from_file( filename, key );
release_object( key );
@@ -1885,7 +1892,7 @@
struct key *key;
current_level = 1;
-saving_lev
Re: wine/ include/Makefile.in dlls/user/user32.spe ... (CVS compile fix)
This patch adds GetScrollBarInfo to user32.spec, but adds no
implementation...
Here's a temporary fix for those wondering why the CVS won't compile
until the rest of Vitaly's scrollbar patch is committed.
Mike
Alexandre Julliard wrote:
ChangeSet ID: 15265
CVSROOT:/opt/cvs-commit
Module name:wine
Changes by: [EMAIL PROTECTED] 2005/01/07 11:15:30
Modified files:
include: Makefile.in
dlls/user : user32.spec misc.c
Added files:
include: winnls32.h
Log message:
Diego Pettenò <[EMAIL PROTECTED]>
Added stub implementation for WINNLS* functions.
Patch: http://cvs.winehq.org/patch.py?id=15265
Old revision New revision Changes Path
1.151 1.152 +1 -0 wine/include/Makefile.in
1.92 1.93 +4 -4 wine/dlls/user/user32.spec
1.19 1.20 +34 -3 wine/dlls/user/misc.c
Added 1.1 +0 -0 wine/include/winnls32.h
? dlls/user/timer.c
? dlls/user/tests/child.c
? dlls/user/tests/child.ok
? dlls/user/tests/timer.c
? dlls/user/tests/timer.ok
Index: dlls/user/painting.c
===
RCS file: /home/wine/wine/dlls/user/painting.c,v
retrieving revision 1.16
diff -u -r1.16 painting.c
--- dlls/user/painting.c4 Jan 2005 12:11:09 - 1.16
+++ dlls/user/painting.c8 Jan 2005 02:53:48 -
@@ -570,3 +570,10 @@
}
return ret;
}
+
+BOOL WINAPI SetLayeredWindowAttributes(HWND hwnd, COLORREF crKey,
+ BYTE bAlpha, DWORD dwFlags)
+{
+FIXME("%p %08lx %02x %08lx\n", hwnd, crKey, bAlpha, dwFlags);
+return TRUE;
+}
Index: dlls/user/user32.spec
===
RCS file: /home/wine/wine/dlls/user/user32.spec,v
retrieving revision 1.93
diff -u -r1.93 user32.spec
--- dlls/user/user32.spec 7 Jan 2005 17:15:30 - 1.93
+++ dlls/user/user32.spec 8 Jan 2005 02:53:49 -
@@ -294,7 +294,7 @@
@ stdcall GetPropA(long str)
@ stdcall GetPropW(long wstr)
@ stdcall GetQueueStatus(long)
-@ stdcall GetScrollBarInfo(long long ptr)
+#@ stdcall GetScrollBarInfo(long long ptr)
@ stdcall GetScrollInfo(long long ptr)
@ stdcall GetScrollPos(long long)
@ stdcall GetScrollRange(long long ptr ptr)
@@ -521,6 +521,7 @@
@ stdcall SetInternalWindowPos(long long ptr ptr)
@ stdcall SetKeyboardState(ptr)
@ stdcall SetLastErrorEx(long long)
+@ stdcall SetLayeredWindowAttributes(long long long long)
@ stdcall SetLogonNotifyWindow(long long)
@ stdcall SetMenu(long long)
@ stdcall SetMenuContextHelpId(long long)
Index: dlls/user/tests/win.c
===
RCS file: /home/wine/wine/dlls/user/tests/win.c,v
retrieving revision 1.39
diff -u -r1.39 win.c
--- dlls/user/tests/win.c 27 Dec 2004 17:26:37 - 1.39
+++ dlls/user/tests/win.c 8 Jan 2005 02:53:49 -
@@ -2114,6 +2114,82 @@
ok( !ret, "message %04x available\n", msg.message);
}
+static void test_child_window()
+{
+WNDCLASSA cls,child_cls;
+char className[] = "parentclass"; /* To make sure className >= 0x1 */
+char winName[] = "parent window";
+char childclassName[] = "childclass"; /* To make sure className >=
0x1 */
+char childwinName[] = "child window";
+HWND hWnd, hChild;
+HINSTANCE hInstance = GetModuleHandleA( NULL );
+
+cls.style = CS_HREDRAW | CS_VREDRAW | CS_GLOBALCLASS;
+cls.lpfnWndProc = DefWindowProcA;
+cls.cbClsExtra= 0;
+cls.cbWndExtra= 0;
+cls.hInstance = 0;
+cls.hIcon = LoadIconA (0, (LPSTR)IDI_APPLICATION);
+cls.hCursor = LoadCursorA (0, (LPSTR)IDC_ARROW);
+cls.hbrBackground = GetStockObject (WHITE_BRUSH);
+cls.lpszMenuName = 0;
+cls.lpszClassName = className;
+
+ok (RegisterClassA (&cls), "unable to register class") ;
+
+hWnd = CreateWindowA (className, winName,
+ WS_OVERLAPPEDWINDOW ,
+ CW_USEDEFAULT, CW_USEDEFAULT, 300, 300, 0,
+ 0,
+ hInstance, 0);
+
+ok(hWnd != 0, "Couldn't create parent window");
+
+child_cls.style = CS_HREDRAW | CS_VREDRAW | CS_GLOBALCLASS;
+child_cls.lpfnWndProc = DefWindowProcA;
+child_cls.cbClsExtra= 0;
+child_cls.cbWndExtra= 0;
+child_cls.hInstance = 0;
+child_cls.hIcon = LoadIconA (0, (LPSTR)IDI_APPLICATION);
+child_cls.hCursor = LoadCursorA (0, (LPSTR)IDC_ARROW);
+child_cls.hbrBackground = GetStockObject (GRAY_BRUSH);
+child_cls.lpszMenuName = 0;
+child_cls.lpszClassName = childclassName;
+
+ok (RegisterClassA (&child_cls) , "unable to register child class");
+
+/* NOTE:WS_POPUP should override WS_CHILD */
+
+hChild = CreateWindowExA (
+ 0, childclassName, childwinName,
+ WS_POPUP | WS_CHILD | WS_CLIPCHILDREN,
+ 50, 50, 50, 100, hWnd,
+ 0, hInstance, 0);
+
+ok(hChild != 0, "Coul
Re: wineloader: call wineprefixcreate with explicit WINEPREFIX
On Fri, Jan 07, 2005 at 10:46:51PM +0100, Tobias Burnus wrote: > Hello, > > Crestez Leonard wrote: > >+if [ -z $WINEPREFIX ] > >+then > While my bash accepts this, Tru64 UNIX's POSIX shell does not. > Please use "$WINEPREFIX" instead. And while you are at it, you could also replace those [ ] used within that script by test, since some Solaris (AFAIR) versions don't contain the [ binary/symlink that is an alternate syntax for an invocation of test. Andreas Mohr
Re: wineloader: call wineprefixcreate with explicit WINEPREFIX
Hello, Crestez Leonard wrote: +if [ -z $WINEPREFIX ] +then While my bash accepts this, Tru64 UNIX's POSIX shell does not. Please use "$WINEPREFIX" instead. Tobias
Re: Debugging mingw applications using wine
Eric Pouech wrote: Could you give any hints as to how to configure GDB with 'stabs in PE' support? The only reference I could find in the GDB documentation is: "6.4.5 PE Windows 95 and NT use the PE (/Portable Executable/) format for their executables. PE is basically COFF with additional headers. While BFD includes special PE support, GDB needs only the basic COFF reader." Is there a configure option to enable this support in the standard BFD/GDB code? (I'm using GDB from CVS head) - or are special patches required? How did you get/build the GDB you use? There's no such things (and it's definitively not an easy task, which still remains to be done, and that Wine decided not to implement some years ago). In that case, what is "winedbg --gdb" for? Why have this option if no GDB supports it? Bryce
Re: Debugging mingw applications using wine
Bryce McKinlay a écrit : Eric Pouech wrote: Bryce McKinlay a écrit : I'm trying to debug a windows .exe built with mingw using wine, but winedbg seems to have problems reading stabs from the mingw-built binary. My goal is to be able to debug a cross-compiled, native Java (GCJ) application, but even a simple C "hello world" seems to cause problems. winedbg using the gdb won't work here because (likely on unix) gdb isn't compiled with proper 'stabs in PE' support you can either: - use bare winedbg (without gdb support) - recompile gdb with 'stabs in PE' support (ie the settings used when compiling gdb under windows) Could you give any hints as to how to configure GDB with 'stabs in PE' support? The only reference I could find in the GDB documentation is: "6.4.5 PE Windows 95 and NT use the PE (/Portable Executable/) format for their executables. PE is basically COFF with additional headers. While BFD includes special PE support, GDB needs only the basic COFF reader." Is there a configure option to enable this support in the standard BFD/GDB code? (I'm using GDB from CVS head) - or are special patches required? How did you get/build the GDB you use? There's no such things (and it's definitively not an easy task, which still remains to be done, and that Wine decided not to implement some years ago). A+ -- Eric Pouech
Re: MSVCRT: Re-implement *printf
Juan Lang wrote: Style point: (*pointer).whatever is written a bit more easily as pointer->whatever. That'd make your new patch a good bit more readable. --Juan __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail D'oh. Can't believe that slipped my mind. Thanks.
Re: MSVCRT: Re-implement *printf
On January 7, 2005 09:04 am, Mike Hearn wrote: > On Fri, 07 Jan 2005 08:46:25 -0800, Juan Lang wrote: > > Style point: (*pointer).whatever is written a bit more easily as > > pointer->whatever. That'd make your new patch a good bit more readable. > > Are they even equivalent? My impression was that (*pointer).whatever would > make a temporary copy on the stack, set it, and then immediately throw > away that copy. So it wouldn't actually set it at all. What I don't think so. Not when I tried it 30 seconds ago. > > If there's a finer point of C I missed here then please do enlighten me ... -- Bill Medland mailto:[EMAIL PROTECTED] http://webhome.idirect.com/~kbmed
Re: MSVCRT: Re-implement *printf
On Fri, 07 Jan 2005 08:46:25 -0800, Juan Lang wrote: > Style point: (*pointer).whatever is written a bit more easily as > pointer->whatever. That'd make your new patch a good bit more readable. Are they even equivalent? My impression was that (*pointer).whatever would make a temporary copy on the stack, set it, and then immediately throw away that copy. So it wouldn't actually set it at all. If there's a finer point of C I missed here then please do enlighten me ...
Re: USER32: GetScrollBarInfo
Vitaly Lipatov <[EMAIL PROTECTED]> writes: > --- scroll.c 8 Dec 2004 18:06:15 - 1.3 > +++ dlls/user/scroll.c4 Jan 2005 14:27:08 - > @@ -27,7 +27,7 @@ > * the specification mentioned above. > * If you discover missing features, or bugs, please note them below. > * > - * TODO: > + * TODO: needs check follow realized functions: > * - GetScrollBarInfo > * - SBM_GETSCROLLBARINFO > * - SCROLLBARINFO > @@ -1424,10 +1461,12 @@ > case SBM_GETSCROLLINFO: > return SCROLL_GetScrollInfo(hwnd, SB_CTL, (SCROLLINFO *)lParam); > > +case SBM_GETSCROLLBARINFO: > +return GetScrollBarInfo(hwnd, SB_CTL, (SCROLLBARINFO *)lParam); You have to do that the other way around, GetScrollBarInfo should send a SBM_GETSCROLLBARINFO message, similar to what GetScrollInfo does. -- Alexandre Julliard [EMAIL PROTECTED]
Re: MSVCRT: Re-implement *printf
Style point: (*pointer).whatever is written a bit more easily as pointer->whatever. That'd make your new patch a good bit more readable. --Juan __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail
Re: Announcing security hardened kernels for testing
> This can't do everything. It protects against return-to-libc style > attacks but there are other stack based attacks that it doesn't work for > (if I remember correctly). I.e. for C++ apps you could instead change the implicit this argument of the caller, for example, to point to a made-up instance with a pointer to a made-up vtable with function pointers to your own stuff :) Cheers, Kuba Ober
Re: winecfg fixes, now with actual patch
Crestez and I talked about this patch on #winehackers, and there are a few things that need to be changed (let's ignore the formatting changes here): - There was code to avoid a crash when the desktop value read from the registry doesn't have an x in it for some reason (yes this does happen) but this patch deletes it - mode_to_label is for translated, UI strings, not for stuff to be put in the registry. It does say this in a comment but I can appreciate that it looks at first glance like pointlessly duplicated code. We should fix this, especially as right now winecfgs translation support is weak. But for now the replacement of a case statement with a mode_to_label call is incorrect. thanks -mike On Fri, 07 Jan 2005 16:44:11 +0200, Crestez Leonard wrote: > This patch makes a bunch of small winecfg fixes. Since most of them are > just a few lines in length I don't think it's worth splitting them. > > Sorry for forgetting the attachment. > > Changelog: > winecfg: fix add application (memory error) > winecfg: fix apply button lighting up in audio tab > winecfg: fix video tab(crash when checking desktop, apply button not > lighting up > winecfg: fix apply button in libraries tab, fix memory leak in > parse_override, remove horrible abuse of macros in set_dllmode
Re: comctl32.dll and commctrl.dll
Rob Shearman wrote: Dripple wrote: Hi all, I'm a newbie in wine using and wine developpement. I just need information about comctl32.dll and commctrl.dll. I'm trying to have this app (http://appdb.winehq.org/appview.php?appId=1485&versionId=2451) working. In fact, it works. But only using native comctl32.dll, which requires native commctrl.dll. Is it planned to fix commctrl.dll, to avoid piracy ? You probably shouldn't admit to copyright infringement on a public mailing list. Rob I think you're jumping to conclusions, Rob; here's the info on the program (from the link) Description Full up-to-date collection of the Watchtower Bible & Tracts Society publications ,including full text of the Bible(very precise "New World Translation of the Hebrew & Greek Scriptures") with links,also 2-Volume "Insight on the Scriptures" -- full encyclopedia of all biblical terms and names,all equipped with full-featured search engine.A powerful tool for Bible study.(Freely distributed by Jehovah's Wittnesses,no URL available) So the program itself appears to be free (libre), even if there's no website to actually get it from ;-) . Now, naturally what is not freely distributable is comctrl.dll, but there's no indication that the OP doesn't have a Windows licence and if Dripple does have such a license, there's no piracy involved, afaik. I have a Win98 licence, insofar as I have a retail copy of Win98 that I bought 5 years ago-- I can copy the comctrl.dll that is on that disk to my Wine installation without breaking any laws, can't I? (Please tell me if not, so I won't do it again ;-) ). Holly
Re: comctl32.dll and commctrl.dll
Dripple wrote: Hi all, I'm a newbie in wine using and wine developpement. I just need information about comctl32.dll and commctrl.dll. I'm trying to have this app (http://appdb.winehq.org/appview.php?appId=1485&versionId=2451) working. In fact, it works. But only using native comctl32.dll, which requires native commctrl.dll. Can anybody explain me what's missing in buitlin comctl32.dll and/or commctrl.dll ? Why don't you tell us? You have obviously tried to run the app with builtin comctl32. Does it crash? Does it draw incorrectly? Does it hang? Is it planned to fix commctrl.dll, to avoid piracy ? You probably shouldn't admit to copyright infringement on a public mailing list. Rob
comctl32.dll and commctrl.dll
Hi all, I'm a newbie in wine using and wine developpement. I just need information about comctl32.dll and commctrl.dll. I'm trying to have this app (http://appdb.winehq.org/appview.php?appId=1485&versionId=2451) working. In fact, it works. But only using native comctl32.dll, which requires native commctrl.dll. Can anybody explain me what's missing in buitlin comctl32.dll and/or commctrl.dll ? Is it planned to fix commctrl.dll, to avoid piracy ? Thanks. Dripple
Re: Announcing security hardened kernels for testing
> Actually, we shouldn't be generating assembly code on the fly. If you > have more than say 16 proxies in a process then it is actually cheaper > in terms of memory usage and cache locality to have a set of compiled > entry points that can be shared by all proxies. It is even better if you > consider the fact that we shouldn't be allocating the memory for the > code from the heap, but should be requesting an executable page of > memory for each. i totally agree with you on this one ;-), but the feasibility of this depends on how dynamic these proxies have to be, i.e., is enough information known at compile/link time to create them in a read-only section or not. for example, the gcc nested function trampolines by their nature must be runtime generated (instantiated) as they need to be both addressable (callable through a normal function pointer) and contain per-instance information - if these proxies have similar constraints, then it's just not possible. [the following is off-topic i think, if you want to discuss it further, feel free to email me in private, i'll be happy to explain everything] > Just for the record, PaX and execshield are trying to solve problems > that are much better solved by other methods that don't break backwards > compatibility. and i completely disagree with you on this one ;-). what PaX and similar approaches solve is not the manifestation of bugs, but rather they put a stop to exploit techniques. the sets of bugs is orthogonal to the sets of exploit techniques, one kind of bug (say a strcpy() based stack overflow) can be exploited by different exploit techniques (say shellcode injection or a forced return into system()). and a given exploit technique say shellcode injection) can be used to exploit different kinds of bugs (say stack and heap overflows, or user supplied format string bugs). PaX & Co prevent certain exploit techniques from working, canary based systems prevent certain bugs from becoming exploitable (i.e., these methods attack the problem from two different dimensions and have a different, not necessarily comparable coverage of the problem space). > One of the best methods is introducing a terminator canary value between > the return address and variables stored on the stack. it's not only not the best method, but it's a rather limited one in its scope as well. for one, canary solutions can detect simple linear overflow bugs only (and for your case, only on the stack, not on the heap or elsewhere), they won't detect non-linear ones, format string bugs, stale pointer uses, or pretty much any other kind of memory corruption bugs. and protecting the return address is useless alone if you're not protecting other pointers (or even normal data) in the stack frames, there's 'literature' on how to exploit overwritten frame pointers, function arguments, etc (search the phrack magazine for details). > Obviously, this requires compiler support (which GCC currently > lacks, I believe) mainline gcc does, however both StackGuard and SSP are available as patches. these days quite a few systems (OpenBSD, Adamantix, Gentoo, etc) are using SSP in their base system. there's also talk about incorporating SSP into mainline gcc, but it'll be a longer process. > but it has worked wonders for Microsoft in SP2. i don't know where you got that from, but it hasn't done much good at all, there're ways to exploit even normal stack overflows that /GS was supposed to prevent (i think David Litchfield posted one on bugtraq or his site), not to mention other kinds of memory corruption bugs which /GS does nothing against. hint: the MS /GS canary doesn't protect the function pointer in the SEH registration record (and the 16 bit randomness in the canary itself is not impossible to brute force either). > It even prevents exploits that PaX/execshield can't, like "return to libc" > where the return address is overwritten by the address of another > function so that execution jumps into that function. /GS doesn't prevent such exploits, it makes them succeed with a small probability only (1 in 65534 or so), which PaX and others also achieve by virtue of randomizing the address space layout (and that is of course much more generic than a mere random canary, it helps to make all kinds of exploits harder, not only linear stack overflows). as for the true protection against ret2libc style exploits, check out the doc on the future plans for PaX (http://pax.grsecurity.net/docs/pax-future.txt).
Native comctl32.dll and native commctrl.dll
Hi all, I'm a newbie in wine using and wine developpement. I just need information about comctl32.dll and commctrl.dll. I'm trying to have this app (http://appdb.winehq.org/appview.php?appId=1485&versionId=2451) working. In fact, it works. But only using native comctl32.dll, which requires native commctrl.dll. Can anybody explain me what's missing in buitlin comctl32.dll and/or commctrl.dll ? Is it planned to fix commctrl.dll, to avoid piracy ? Thanks. Dripple
tools/widl/write_msft.c warnings
The addition of tools/widl/write_msft.c added the following four warnings, basically doubling the number of warnings we are getting with GCC 3.4. write_msft.c:582: warning: `ctl2_alloc_importinfo' defined but not used write_msft.c:620: warning: `ctl2_alloc_importfile' defined but not used write_msft.c:918: warning: `ctl2_find_nth_reference' defined but not used write_msft.c:1382: warning: `set_help_file_name' defined but not used Would you mind looking into this? Gerald
Re: Announcing security hardened kernels for testing
On Fri, 2005-01-07 at 13:46 +0100, [EMAIL PROTECTED] wrote: > i totally agree with you on this one ;-), but the feasibility of this > depends on how dynamic these proxies have to be, i.e., is enough > information known at compile/link time to create them in a read-only > section or not. The thunks we're talking about push an index onto the stack and then call a function, so technically we could pre-generate lots of thunks at compile time that do this but it'd put an upper limit on the number of vtable entries you could have which I'm not keen on. They might also push an object ptr as well, I don't remember ...
Re: [winegcc] Include .so files when calling winebuild
On 6 Jan 2005, Alexandre Julliard wrote: > I'm not sure I follow you, if your .so files have been built correctly > they shouldn't contain undefined references to Windows APIs. Could you > please show an example of the situation that causes a problem? On Thu, 6 Jan 2005, Dimitrie O. Paun wrote: > Of course, there is the bigger problem of why you need these in there. > In fact, in the beginning of winegcc, we used to pass them to winebuild, > but we've stopped long time ago. Hmm, okay - it seems that I am going down the wrong road. I have a project with ca. 10 libraries with source, 2 binaery only dll, and 3-4 projects that uses all of these libraries. I have a goal of replacing/porting one of the binaery only dlls. This perticula dll is use all over the place. When replaceing one functionallity at a time from the dll, I want it to be link at one place only (otherwise some libraries would use the real dll, other my reemplentation). Therefor the libraries are just created by gcc -shared -o foo.so *.o, and the handling the symbols are first done when linking to one of the 3-4 projects. Which brings me back to the questions; at the linking time some symbols in the shared libraries might use symbols in the dll, that are not dealt with (used in the project I am compiling). Does that make sense? There is might be the road of building the libraries static, which winegcc seems to parse to winebuild. Peter
