"Dan Kegel" wrote:
> Looking at http://bugs.winehq.org/show_bug.cgi?id=17181
> I get a feeling that we really need some
> testcases to verify we conform to the 16 bit MS-DOS
> API. Yeah, even though 16 bit is on the way out,
> there's still some use for a few win16 programs, and
> they use MS-D
"Dan Kegel" wrote:
>>> Compiling DOS code to a .com file will produce a very small
>>> executable, then embedding it into the test, put it in %TEMP%,
>>> and exec should be trivial. No need for external tools IMO.
>>
>> I thought of that, it's tempting.
>>
>> But nasm is pretty common; I don't kn
"Jérôme Gardou" wrote:
> Quite oddly enough, wined3d and winex11 don't communicate with each
> other at all (well, wined3d uses WGL in gdi32, and gdi32 is based on
> winex11), and this leads to problems which are tricky to resolve... For
> instance, when a d3d application wants to disable screens
"Hans Leidekker" wrote:
> IE7 imports these and possibly others by ordinal.
>
> -Hans
>
> diff --git a/dlls/mlang/mlang.spec b/dlls/mlang/mlang.spec
> index 1e8f022..689ad27 100644
> --- a/dlls/mlang/mlang.spec
> +++ b/dlls/mlang/mlang.spec
> @@ -1,14 +1,15 @@
> +112 stdcall ConvertINetUnicodeT
"Florian Tobias Schandinat" wrote:
> this test shows a difference between Win9X and NT. (tested on Win98SE
> and WinXP) Some apps expect the Win9X behaviour to work. I don't know
> what's the right way to fix it. Any advice or patch is welcome.
How do that apps work under NT based Windows versio
"Jeremiah Flerchinger" wrote:
> Stubs basic DDE interface of Progman.exe. Similar to Progman stub in
> shell32.dll. Both will need to be extended and a 3rd progman interface
> will need to be added in user32.
Progman DDE interface should be implemented by shell32.dll, nowhere else.
--
Dmitry.
"Jeremiah Flerchinger" wrote:
>> > Stubs basic DDE interface of Progman.exe. Similar to Progman stub in
>> > shell32.dll. Both will need to be extended and a 3rd progman interface
>> > will need to be added in user32.
>>
>> Progman DDE interface should be implemented by shell32.dll, nowhere else
"Aric Stewart" wrote:
> diff --git a/dlls/wininet/internet.c b/dlls/wininet/internet.c
> index 363f7a4..7db635d 100644
> --- a/dlls/wininet/internet.c
> +++ b/dlls/wininet/internet.c
> @@ -2367,8 +2367,35 @@ BOOL WINAPI InternetSetOptionW(HINTERNET hInternet,
> DWORD dwOption,
> case INTERNE
"Jeremiah Flerchinger" wrote:
> Explorer.exe now calls ShellDdeInit. Progman stubs will now be started/used
> in Shell32.
> Amazingly any apps with a Progman DDE interface will also be called. Shell32
> can handle
> all major functionality, but a running progman.exe (for example) will be able
"Austin English" wrote:
> Perhaps we should wait for bugs to be closed by AJ in the next
> release, even if they were fixed in a previous release? That way, they
> should up in the release notes.
>
> Dan brought it up on another bug, and I agree...but figured it should
> be brought up here.
>
>
"Paul Bryan Roberts" 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 simultaneou
"Paul Bryan Roberts" wrote:
>> 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.
>>
> Ah, right you are, thanks.
>
> I guess that shou
"Paul Bryan Roberts" wrote:
>> You need to generate the patch from the top of the wine directory. You
>> also need to use your real name for copyright-tracking purposes.
>
> "copyright-tracking purposes"
>
> is there a Wiki page that explains this to the uninitiated ? I looked,
> did not find.
"Paul Bryan Roberts" wrote:
> I did reference the piclist web-page in the analysis I attached to bug
> 14334 but accept that no one is ever likely to read it.
The description of API parameters in your patch looks like directly copied
from that page, so you should either write it in your own wor
"Austin English" wrote:
> +/* create a temporary file */
> +uUnique = GetTempFileNameA(tempdir, "pfx", 0, source);
> +ok(uUnique != 0, "GetTempFileNameA error %d\n", GetLastError());
> +
> +/* get the same filename as above with upper case
> + prefix and without creating any
"Juan Lang" wrote:
> + hr = VarR8FromDec((DECIMAL *)pDecIn, &dbl);
According to PSDK VarR8FromDec() takes a const pointer to the 1st parameter,
to it should be fixed instead of casting const out.
Same for VarDecInt() patch.
--
Dmitry.
"Steven Edwards" wrote:
> Conversely maybe using windows.h usage should be fixed and used more
> often. Wine is an oddball when it comes to win32 program with the
> excessive lengths it goes to, to avoid using windows.h. I am starting
> to think even avoiding it internally like we do causes more
"Steven Edwards" wrote:
> I've agreed with the logic and the reasons behind it for the Wine
> libraries. My point was that we already avoid it more than enough in
> libraries, and maybe its a good thing after far as winelib goes to
> insure the apps in the programs directory always do include win
"Igor Tarasov" wrote:
> Now I don't get it. Looked through listview tests and there are not
> even one mouse-related test. And my patch could be tested by just
> sending HDN_ITEMCLICKW to listview control. And capturing the response
> notifications.
Then just do it that way.
> But the code is:
"Drew Ronneberg" wrote:
> -ok(exit_code == 0x || /* Win 9x */
> - exit_code == 0x80 || /* NT4 */
> - exit_code == STATUS_DEBUGGER_INACTIVE, /* Win >= XP */
> +ok(exit_code == STATUS_DEBUGGER_INACTIVE || /* Win >= XP */
> + broken(exit_code ==
"Dimi Paun" wrote:
On Wed, 2009-03-04 at 11:59 -0600, John Klehm wrote:
I wouldn't really want per save captcha either, per account creation
is what I was hoping would cut down the spam. If the accounts are
created manually not much we can do about it :(
I think that's the case. Which is wh
"Vitaliy Margolen" wrote:
Please disable file attachments on Wiki. There are no way to verify their
validity and for the past week it's been a constant source of spam.
IMHO file attachment does not belong on text only Wiki. If anyone needs to
attach a patch a two - they can link it to the one
"Dmitry Timoshkov" wrote:
It would be also helpful to to get all wiki user account list (check it
time from time for suspicious names) and have an ability to delete accounts
of known spammers for Wiki admins. Is it possible?
Another thing that would probably help to get rid o
[please don't forget to cc: wine-devel]
"Jeff Latimer" wrote:
It would be also helpful to to get all wiki user account list (check it
time from time for suspicious names) and have an ability to delete
accounts
of known spammers for Wiki admins. Is it possible?
Another thing that would proba
"Francois Gouget" wrote:
What's the point in having a Wiki account then?
Being able to modify the Wiki pages.
Being notified of changes to specific Wiki pages.
As far as I know you cannot do that if you don't have an account. But
personally I really don't want yet one more home page to main
"Ben Klein" wrote:
Another thing that would probably help to get rid of spammers' accounts
is to (regularly) delete all user accounts without a personal page.
It would also get rid of anyone who did not want to create a home page.
It would also attract spammers to creating personal pages.
"Rosanne DiMesio" wrote:
> As I said having a short description what your intentions/activity is in
> the Wine project is enough, no burden/obligations to update it.
So, if a user notices a typo in the wiki and is nice enough to take
the time to correct it, you want to require them to also a
"Dimi Paun" wrote:
And I'll like to see some data that shows that we have a
significant portion of the spammers are bots before we
even start thinking of captchas.
http://wiki.winehq.org/RecentChanges has all the details. Please
consider at least removing the spammers' accounts listed there,
"Massimo Del Fedele" wrote:
PATH_ExtTextOut() uses GetGlyphOutlineW() which can return a NULL buffer
size not just on errors but also on non-printable glyphs.
Instead of aborting the function should check for such cases, get the
metrics and continue.
This patch doesn't match the normal logic
"Michael Stefaniuc" wrote:
Alexandre doesn't want to accept that patch. See
http://www.winehq.org/pipermail/wine-devel/2009-January/072151.html
Hmm, clearly there are other places in that file that already
do casting, and that's the only place where there is no one.
--
Dmitry.
"Anssi Hannula" wrote:
Better if Wine would use fontconfig's configuration as set by desktop
environment (~/.fonts.conf).
That's not a very good idea, see http://bugs.winehq.org/show_bug.cgi?id=16745
for details.
--
Dmitry.
"Massimo Del Fedele" wrote:
This patch doesn't match the normal logic of ExtTextOut implemented
in dlls/winex11.drv/xrender.c, also this requires a test case for
both code paths.
Why ? As is it now PATH_ExtTextOut() simply returns FALSE on first space
or non-printable glyph, you can see eas
It would be cleaner to check for GDI_NO_MORE_WORK in
SaveDC/RestoreDC instead of duplicating their code.
--
Dmitry.
"Chris Robinson" wrote:
Why not make the default what the filesystem actually is? Eg. if the FS is
FAT32, report FAT32; if it's NTFS, report NTFS; if it's a unixfs, report
unixfs; etc. The registry/winecfg can then be used to override the per-drive
type if it causes problems with certain apps
"Vincent Povirk" wrote:
> Isn't that the python test's fault, then? Why can't c:\bin\sh exist?
On a real windows system, it won't.
It won't by default, but can't a user create it?
A real user who is trying to get real work done won't.
A real user who is trying to get real work done won't
wrote:
+#define compare_fourcc(fcc1, fcc2) (((fcc1)^(fcc2))&~0x20202020L)
You ignore case even for mixed cased fourcc codes, but test only
2 cases: all lower/upper case codes, please test that cases too.
--
Dmitry.
"Igor Tarasov" wrote:
So, does that mean that I have to add new flag to the structure that
would be set only if that field is changed, or there is another way to
do that?
First thing to do (as usually) is write a bunch of tests and get them
committed.
--
Dmitry.
"Stefan Leichter" wrote:
[mountmgr.sys] add unittests for registry keys of serial ports
The closest match these tests belong to is dlls/kernel32/tests/comm.c
Is there any app that checks for a registry key instead of using an API?
--
Dmitry.
"Stefan Leichter" wrote:
The closest match these tests belong to is dlls/kernel32/tests/comm.c
I asked where to put the implementation before i started codeing see
http://www.winehq.org/pipermail/wine-devel/2009-April/074476.html
That's for implementation, the tests belong to the place whe
"Paul TBBle Hampson" wrote:
+/* Make sure we haven't already got an entry for this due to
substitution */
+duplicate = FALSE;
+LIST_FOR_EACH_ENTRY(system_font_link, &system_links, SYSTEM_LINKS,
entry)
+{
+if(!strcmpW(system_font_
"Hans Leidekker" wrote:
+/*
+ * ___lc_handle_func (MSVCRT.@)
+ */
+HANDLE * ___lc_handle_func(void)
+{
+return MSVCRT___lc_handle;
+}
+
+/*
+ * _
"Massimo Del Fedele" wrote:
The approach taken so far consisted in having 2 device pointers inside GDI32,
one for dib engine and
the other for normal display driver.
Please don't post huge attachments to the mailing list in future,
post url for them instead.
--
Dmitry.
"Colin Finck" wrote: wrote:
@@ -425,6 +425,7 @@ static LPWSTR get_url(void)
HKEY hkey;
DWORD res, type;
DWORD size = INTERNET_MAX_URL_LENGTH*sizeof(WCHAR);
+DWORD returned_size;
LPWSTR url;
static const WCHAR wszGeckoUrl[] = {'G','e','c','k','o','U','r','l',0};
@
"Paul TBBle Hampson" wrote:
+if (strlenW(lpszStart)==0)
+{
+/* Skip 0-length headers */
+lpszStart = lpszEnd;
+bSuccess = TRUE;
+continue;
+}
Instead of 'if (strlenW(lpszStart)==0)' it's much simpler to do
'if (!*lpszStar
"Eric Pouech" wrote:
--- a/dlls/kernel32/editline.c
+++ b/dlls/kernel32/editline.c
@@ -818,7 +818,7 @@ WCHAR* CONSOLE_Readline(HANDLE hConsoleIn)
/* EPP WCEL_Dump(&ctx, "before func"); */
ofs = ctx.ofs;
/* mask out some bits which don't interest us */
-ks = ir.Event.KeyEvent.d
Hi Dimi,
"Dimi Paun" wrote:
On Sat, 2009-03-14 at 00:59 +0800, Dmitry Timoshkov wrote:
http://wiki.winehq.org/RecentChanges has all the details. Please
consider at least removing the spammers' accounts listed there,
I have done that in the past, and I'll keep removing t
And what is the reason of the crash? Please add a test case
replicating the problem first.
--
Dmitry.
"Stefan Leichter" wrote:
+/***
+ * ExtractVersionResource16W (SHELL32.@)
+ */
+BOOL WINAPI ExtractVersionResource16W(LPWSTR s, DWORD d) {
+FIXME("(%s %x) stub!\n", debugstr_w(s), d);
+return FALSE;
+}
Ple
"Stefan Leichter" wrote:
Also you might be interested that according to
http://www.geoffchappell.com/viewer.htm?doc=studies/windows/shell/shell32/h
istory/names351.htm ExtractVersionResource16W is discontinued starting from
Windows Vista.
What does the second point means for wine?
That mean
"Josef Simánek" wrote:
I edit Makefile and type make into console.
What exactly did you do? notepad is not supposed to work as a console
application for your information.
My problem above. In the
guide is written to report bad compiling behaviour. So I did it. Any
hints ?
mirindos...@mirin
"André Hentschel" wrote:
now with LVITEMW and SNDMSGW
You are still casting to LPLVITEMA in ListView_SetCheckState while
using LVITEMW and SNDMSGW. As been said by using SNDMSGW/LVITEMW you
are making these macros incompatible with PSDK ones, and breaking
compatibility if someone will try to
"André Hentschel" wrote:
LRESULT CALLBACK ChildWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM
lParam)
{
+HKEY hKey;
+LPWSTR lpKeyPath;
switch (message) {
case WM_CREATE:
Indentation is weird. And an empty line after variables won't hurt.
--
Dmitry.
"Gerald Pfeifer" wrote:
static LRESULT
-REBAR_GetPalette (const REBAR_INFO *infoPtr, WPARAM wParam, LPARAM lParam)
+REBAR_GetPalette ()
{
(void) is mandatory, please don't omit it.
--
Dmitry.
"Vincent Povirk" wrote:
With a test program that uses CoWaitForMultipleHandles in a single-thread
apartment as a main loop, I found that on Windows all sent messages were
processed, the program's window did redraw, keyboard and mouse input was
ignored, and only posted messsages from 0x3e0 throu
"James McKenzie" wrote:
Austin:
Contact Mike Kronenberg or Zach Drayer and see what they currently
have.
IMHO since they haven't even bothered so far to change the license from
GPL to LGPL to match Wine, and clarify what exactly is so much different
in their builds so that they insist on dif
"Massimo Del Fedele" wrote:
The driver loading mechanics is the gdi32 one duplicated in winedib.drv.
winedib.drv just intercept DIB calls and forward others to *any* other
driver. Again, in my thoughts that is a "transient" phase, at the end all
dib processing should go inside gdi32.
Probably
"André Hentschel" wrote:
This converts the DDE-Callbackfunction to Unicode.
After days of winebrowser-hacking i turned it down to this clean code.
It uses the function IsTextUnicode instead of guessing.(IsTextUnicode is
guessing too, but in a cleaner way)
Please add a test case which uses mi
"André Hentschel" wrote:
Please add a test case which uses mixed ansi/unicode DDE client/server
and only then start fixing the code.
For winebrowser? Do we test any of our programs? Or for DDE?
Quoting above: "mixed ansi/unicode DDE client/server".
--
Dmitry.
"Jeff Latimer" wrote:
I put tests for the mixed conditions in test/dde.c quite a while ago:
Then it should be obvious where the fix should be added, with
removing todo_wine in appropriate places.
--
Dmitry.
"Austin English" wrote:
Why do we have versions on Mac OS X? How about we combine them all?
It can make a big difference in the bug. The X.org version in OS X
(partially?) depends on what OS X version you have. Some bugs will
only show up in Tiger, because Leopard has them fixed on Apple's en
"Stephan Rose" wrote:
So if anyone can drop a full spec into my lap which outlines everything
I need to write and where (given I adhere to things as I should of course)
I won't have any issues getting that accepted later on, I'd be more than
willing to take on something like this.
Anyone need
"Rico Schüller" wrote:
-/* version info? */
-skip_dword_unknown(&ptr, 2);
+/* Compiled target version (e.g. fx_4_0=0xfeff1001, fx_4_1=0xfeff1011). */
+read_dword(&ptr, &e->version);
+TRACE("Target: %#x\n", e->version);
0xfeff/0xfffe is a unicode byte order mark, could it s
"chris ahrendt" wrote:
Using this attached Reg File Is still a no go... same...
(I forgot the Direct3D tag but added it and no change)
Have you heard of a regression testing? Also wine-devel is not
an appropriate place to report bugs.
--
Dmitry.
"Michael Martin" wrote:
The following patch fixes 18130. In my tests, context menu for
the Edit window control does not send the WM_COMMAND message.
Please comment.
And what is the reason of the crash? Please add a test case
replicating the problem first, only then start fixing it.
--
Dmitry
"Igor Tarasov" wrote:
2009/6/9 Austin English :
Users are editing their posts when asked for terminal output/wine
version/etc. Those of us on the mailing list side don't get this
information.
Maybe just add notice on edit page stating that edits are for minor
changes only, and if one has som
"Alex Villacís Lasso" wrote:
I recently filed http://bugs.winehq.org/show_bug.cgi?id=18734 in which I showed that DlgDirList is behaving
incorrectly for 16-bit apps. I also included a test program compiled with the Watcom C compiler, as well as a patch.
Then a comment appeared saying that it
"Paul Vriens" wrote:
These new tests introduce some failures on Win9x. Could you have a look?
It's because HWND_MESSAGE support is missing in win9x.
--
Dmitry.
"Austin English" wrote:
> These new tests introduce some failures on Win9x. Could you have a look?
It also broke the gdi32:font, gdiplus:font, and user32:edit tests for me, see:
http://test.winehq.org/data/45629dc050f46988c23ded35ad18bbd8c63e4e65/wine_ae-ub904/report.html
These tests shouldn
"Paul Vriens" wrote:
These new tests introduce some failures on Win9x. Could you have a look?
It's because HWND_MESSAGE support is missing in win9x.
OK, will have a shot at this.
Perhaps PeekMessage() sets a reasonable last error code in that case
which you can test for, and 'continue;'.
"Paul Vriens" wrote:
Perhaps PeekMessage() sets a reasonable last error code in that case
which you can test for, and 'continue;'.
Well actually, I've improved/corrected the ok() messages and it shows:
msg.c:11637: Test failed: 0: got ret 1 hwnd 0224 msg 0171 wParam
1234 lParam
"Paul Vriens" wrote:
There is nothing (apart from the failures of course) that indicates
Win9x (last error doesn't change).
We could of course use CreateWindowExW instead of A ?
That's an easiest solution, yes.
--
Dmitry.
"André Hentschel" wrote:
Fair enough. We tend to mimic Windows behavior. I hadn't checked
this myself. Note that it still should be Install*.exe rather than
Instal*.exe, at least in English.
--Juan
My tests worked with Instal*.exe files on english Windows, too.
I bet it is because of the in
"Francois Gouget" wrote:
On Mon, 22 Jun 2009, Frédéric Delanoy wrote:
[...]
> Furthermore,
> - the "65001" should probably be replaced by "utf8" (I checked in
> tools/wrc/parser.l:373) [ which would be better IMNSHO in new/updated
> resource file]
Do the Windows/Mingw resource compilers suppor
"Pavel Procházka" wrote:
Subject:[2/3] wined3d: IWineGDISwapChainImpl_Present relevant to windows
implementation
Making multibuffering working well when flip - sequence is W RGB, R GBW, G BWR, B WRG, W RGB. When W = WHITE, R =
RED, G = GREEN, B = BLUE. It is doing well for any count of backb
wrote:
Yesterday I edited http://wiki.winehq.org/MacOSX/FAQs to be much less
outdated than before and today I found that Dmitry Timoshkov removed
all references to Mike Kronenberg's Wine binary distribution at
http://www.kronenberg.org/darwine/
The explanation is here:
"Maik Schulz" wrote:
IMHO, it would be sufficient to add a "not supported by winehq.org"
disclaimer next to the mention. If there currently is no binary
distribution that packs the vanilla wine tree then you're making it
unnecessarily difficult to obtain a binary distribution for the Mac O
"Emmanuel Maillard" wrote:
Darwine tools WineHelper and create_darwine_distrib script are not GPL
but LGPL.
Don't know for Mike Kronenberg patches or other stuffs, but we never
change Wine licensing
in Darwine.
Darwine site claims that it's under GPL. In any case different name means
a di
"Christoph von Wittich" wrote:
+ if (*pcbProvName > INT_MAX)
+ *pcbProvName = INT_MAX;
In which way WideCharToMultiByte is broken? It always helps to provide
an explanation and if possible a test case.
--
Dmitry.
"Christoph von Wittich" wrote:
When you would have a look at the winetests you would have noticed two
failures about passing in negative values...
Which winetests should I look at? The WideCharToMultiByte ones? Then
the patch is wrong. That's unusual to expect that somebody reads your
mind.
"Yuriy Kaminskiy" wrote:
Well, no answer so far; I thought "should write test, code is more welcomed than
just words", and noticed that such test already present, but disabled :-E.
That's wrong. If test report breakage, it should not be simply silenced and
forgotten for 6 years.
See "[rfc] [ker
"Yuri Khan" wrote:
+void selection_acquire(void)
Should be 'static'.
+DWORD WINAPI selection_thread_proc(LPVOID lphwnd)
Should be 'static'. What's the purpose of such a parameter name?
'dummy', 'unused' or just 'param' would be better IMO.
+{
+HANDLE handles[1];
+
+selection_acq
"James McKenzie" wrote:
As you state (AJ): A test case would be great to show what Windows(TM)
and what Wine does to see if the patch really fixes the problem.
Windows(TM) does nothing with resource files.
--
Dmitry.
"Aric Stewart" wrote:
Corrects a large number of font issues with east asian programs.
-if(csi.fs.fsCsb[0] & (face->fs.fsCsb[0] |
face->fs_links.fsCsb[0])) {
+if((csi.fs.fsCsb[0] & (face->fs.fsCsb[0] | face->fs_links.fsCsb[0])) && (face->fs.fsCsb[0] & FS_LATIN1))
{
"Adam Strzelecki" wrote:
I can see real paradox here. Being against using Objective-C is
supposed to bring wider support to the code (right?), but implies
requirement of using either Carbon or Mac OpenGL + Core libraries,
which are far LESS popular, have far LESS active programmers and LES
"Aric Stewart" wrote:
Ok maybe you could help me brainstorm a better fix.
The issue I am seeing is that this application is a chinese application
and it is asking for Tahoma for GB2312_CHARSET. The Tahoma in the
system does not have GB2312_CHARSET. So we end up falling all the way
back to
"Aric Stewart" wrote:
The problem with font linking is that it is hard to generalize. unless
wine installs the font we cannot guarantee that the font is present on
the users system and that is worrisome to me.
I have seen this issue a lot in my working with asian games ported to
english loc
"Austin English" wrote:
Can you possibly add a testcase for this to prevent further regressions?
As far as I can see that was an existing bug, and it only
affects internal treeview item state.
--
Dmitry.
"Scott Ritchie" wrote:
I'll blog about this and post a few forum threads as well. I wanted to
see how wine-devel would act last night before I went to sleep - suffice
to say it's already interesting!
I think it's a matter of the fact that only Wine developers can
fix Wine bugs. Another fact
"F Capela" wrote:
XkbSetDetectableAutoRepeat is not working correctly on some
distributions, including Ubuntu 9.04. In practical terms, this
means programs running under Wine on such distros are unable to
ignore autorepeat, doing strange things to games that use keyboard
controls, for example.
"Michael Karcher" wrote:
The meaning of "enable" is the same in Windows and Wine: it enables the
execute permission, not the data execution prevention. This patch precedes
the test as the inverted logic would make the test case fail in interesting
ways. There is no sense in first adding a lot o
"Michael Karcher" wrote:
The tests will be skipped on Wine until next patch, as the
not-yet-implemented NtQueryInformationProcess(...,ProcessExecuteFlags,...,...)
call is used to detect a DEP-capable platform.
These tests should added to existing dlls/ntdll/tests/exception.c
framework.
--
Dm
"Damjan Jovanovic" wrote:
Think Wine doesn't accept patches easily, and it's hard to get
feedback? Think again.
I think it's not worth an effort to take seriously one post of
apparently clueless anonymous user and a forward to wine-devel
of another anonymous user. We've been through this "mai
"Aric Stewart" wrote:
@@ -5792,6 +5792,9 @@ static BOOL load_child_font(GdiFont *font, CHILD_FONT
*child)
child->font->scale_y = font->scale_y;
hfontlist = HeapAlloc(GetProcessHeap(), 0, sizeof(*hfontlist));
hfontlist->hfont = CreateFontIndirectW(&font->font_desc.lf);
+/* ensur
"Aric Stewart" wrote:
load_child_font calls neither WineEngCreateFontInstance nor GetEnumStructs.
It allocates the the child font structure above in the function sets the
few fields it thinks it needs and then goes on. I see no evidence that
it is being expected to have been set at any other
"Vladimir Pankratov" wrote:
Added Russian translation.
Changed files:
dlls/kernel32/nls/winerror_rus.mc
dlls/kernel32/Makefile.in
What's the point in resending the same version of the patch again
and again without even answering the questions, or addressing the
pointed out problems?
Again,
"Vladimir Pankratov" wrote:
Thanks for suggestions.
Added Russian translation.
Changed files:
dlls/kernel32/nls/winerr_rus.mc
Please stop. This is not a translation. I'd suggest to stop accepting
your other "translations" and patches as well.
--
Dmitry.
"Andrew Eikum" wrote:
---
dlls/user32/tests/input.c | 210
+
1 files changed, 210 insertions(+), 0 deletions(-)
It would be more natural and would simplify the code to add these
tests to msg.c.
Also, please try to avoid names like g_keyStatus,
"André Hentschel" wrote:
--- a/dlls/comctl32/theme_button.c
+++ b/dlls/comctl32/theme_button.c
@@ -30,8 +30,22 @@
#include "uxtheme.h"
#include "tmschema.h"
#include "comctl32.h"
+#include "wine/winuser16.h"
I very much doubt that win16 apps have an idea about theming, or
BM_SETSTATE16 is sup
Hi Andrey,
"Андрей Пономаренко" wrote:
I'm from Institute for System
Programming of Russian Academy of Sciences and we are developing a free
lightweight tool for checking backward/forward binary compatibility of
shared C/C++ libraries in OS Linux. It checks interface signatures and
data type
"Vladimir Pankratov" wrote:
Added Russian translation.
Changed files:
dlls/kernel32/nls/winerr_rus.mc
I think it's been said enough about your "translation". I'm not
going to spend more time commenting on it, I hope Alexandre will
ignore all future attempts as well.
--
Dmitry.
1 - 100 of 2797 matches
Mail list logo
