Jeremy Newman [EMAIL PROTECTED] wrote:
Someone on the list has the virus Sobig.f and sent it to wine-devel on Wed
Aug 20 2003 - 23:18:18 CDT
We MUST remove the infected message from the wine-devel archive.
I'd be happy to remove it. On a quick scan however, I was not able to
find any
Steven Edwards [EMAIL PROTECTED] wrote:
-#define LANG_DIVEHI 0x65
-#define LANG_GALICIAN 0x56
-#define LANG_KYRGYZ 0x40
-#define LANG_MONGOLIAN 0x50
-#define LANG_SYRIAC 0x5a
The above defines present in winnt.h from the Platform SDK.
You have to update
José Manuel Ferrer Ortiz [EMAIL PROTECTED] wrote:
Hi again, attached you have a patch to the spanish
keyboard that adds support to write the Euro sign
using Alt-GR + E, as seen in newer spanish
keyboards.
XFree86 4.3.0 has no this, which however should not prevent
the Euro sign to work.
Maxime Bellengé [EMAIL PROTECTED] wrote:
According to MSDN, it is said that CreateCompatibleBitmap should be used
whenever a color bitmap is created.
Moreover, with CreateBitmap, I have to know the depth of the screen
whereas with CreateCompatibleBitmap I don't need to.
Dmitry (or others),
Maxime Bellengé [EMAIL PROTECTED] wrote:
- hdc = CreateCompatibleDC(0);
- hbm = CreateCompatibleBitmap(hdc, 48, 16);
hbm is a 1 bit per pixel bitmap
+ hdcScreen = CreateDCA(DISPLAY, NULL, NULL, NULL);
+
+ hdc = CreateCompatibleDC(hdcScreen);
+ hbm =
Eric Pouech [EMAIL PROTECTED] wrote:
Why don't you use _lclose, _lcreat, _llseek, _lopen, _lread, _lwrite
exported from kernel32?
except for _lopen which differs a bit from CreateFile, but why not using
ReadFile, WriteFile, CloseHandle...
Because they look too hard for Gregory... Did
Dominik Strasser [EMAIL PROTECTED] wrote:
The attached patch hacks^H^H^H^H^Hfixes this problem. Obviously, this
binary doesn't contain a valid PE header. OTOH it seems to be a valid
Windows binary (I haven't checked it myself). Maybe somebody with a more
deep insight into this can come up
Maxime Bellengé [EMAIL PROTECTED] wrote:
Changelog:
* Fix the creation of treeview with checkboxes. Now they display fine.
The only real change in this patch is the following snippet. Could you
retest and send only that chunk alone?
@@ -4848,12 +4850,14 @@
DrawFrameControl(hdc, rc,
Eric Pouech [EMAIL PROTECTED] wrote:
So, it looks like somewhere in FindClose Wine is resetting the last
error. I started digging through there and the functions it calls but I
was unable to find where it was getting reset. Can anyone shed some
light on this? Is there any way to
Gregory M. Turner [EMAIL PROTECTED] wrote:
One ritual is that you should not use msvcrt from other dlls, this
will cause trouble with apps that use the Unix libc.
Is it OK to do LoadLibrary/GetProcAddress, or is that equally problematic?
Why don't you use _lclose, _lcreat, _llseek,
Dmitry Timoshkov [EMAIL PROTECTED] wrote:
My test under win2k shows that Windows sends
WM_SYSCOMMAND/SC_CLOSE and then WM_CLOSE regardless whether CS_NOCLOSE
is set or not.
Wrong. Please ignore that chunk of the patch. If other parts are OK I'll
resend the whole thing.
--
Dmitry.
Phil Krylov [EMAIL PROTECTED] wrote:
With the current CVS, I can't get any Cyrillic input with any setting
of LANG: ru_RU.KOI8-R, ru_RU.UTF-8, ru_RU.CP1251, and en_US.UTF-8.
Only ? characters are input.
Even if you set LC_ALL=ru_RU.KOI8-R? A good test is to run 'xev' and
see whether it works
Tom [EMAIL PROTECTED] wrote:
+ liADD - RCPT4 ToDo and entries/li
Sorry, didn't notice it first time: it seems that RCPT4
should actually be RPCRT4.
--
Dmitry.
Phil Krylov [EMAIL PROTECTED] wrote:
DT Could you try to investigate what really returns XmbLookupString for
DT UTF-8 locale?
It returns 0.
What version of XFree86 are you using? Could you send me a log using
current cvs: +x11drv,+event,+key,+keyboard?
--
Dmitry.
Alexandre Julliard [EMAIL PROTECTED] wrote:
I think it's much better, drawing directly will cause a lot of
problems, especially when called from another thread context. Unless
you really have an app that depends on not getting a WM_NCPAINT here I
see no reason not to use the normal
Tom [EMAIL PROTECTED] wrote:
Here is a small update to the status pages.
+ liRemove - Some of the bullets from DierctX section/li
an apparent typo above
--
Dmitry.
Dimitrie O. Paun [EMAIL PROTECTED] wrote:
The idea is to have the same defines as Windows; even though we don't
actually need them at this point we might want to someday.
Sorry, I don't quite understand: these defines are present only when
compiling user32. Now, how do we know what
Phil Krylov [EMAIL PROTECTED] wrote:
XFree86 -version reports:
XFree86 Version 4.3.0
Release Date: 27 February 2003
X Protocol Version 11, Revision 0, Release 6.6
Build Operating System: Linux 2.4.22_pre2-gss i686 [ELF]
Build Date: 23 July 2003
The log you asked for is attached. It's
Raul [EMAIL PROTECTED] wrote:
couple years ago, when i sent the estonian layout patch, worked fine
put now im using redhat 9 and detects wrong layout (Latin American
keyboard layout)
is there some changes that breaks the layout or im making something wrong?
The changes have been made on the
Shachar Shemesh [EMAIL PROTECTED] wrote:
I have asked you this before in private, but I fear I didn't really
understand the answer. When I ran with an incorrect locale setting
(en_US.utf8 instead of en_US.UTF-8), konsole would display Hebrew
characters using the UTF-8 encoding.
Phil Krylov [EMAIL PROTECTED] wrote:
But ru_RU.UTF-8 works with the following patch to keyboard.c (but it
won't work on XFree86 3.x):
--- keyboard.c 2003-08-12 19:23:29.0 +0400
+++ keyboard.c-mine 2003-08-12 19:39:21.0 +0400
@@ -1840,7 +1840,7 @@ INT
Shachar Shemesh [EMAIL PROTECTED] wrote:
There is one thing that still bothers me. When using right-win for group
toggle, I get a ` printed when switching from group 0 to group 1, and
; when switching from group 1 to group 0. Otherwise, everything works
fine. This does not happen when
Shachar Shemesh [EMAIL PROTECTED] wrote:
BTW, what wrong happens if your keyboard was misdetected? In the current
CVS all national characters should work fine regardless what keyboard
layout was detected. Is that only a warning message which makes you worry?
Does this also apply to
[EMAIL PROTECTED] wrote:
I had to use with-nptl to build winex pn Mandrake 9.1, the binarys did't work
without that option. This wasn't necessarry on wine, but winex won't run without it.
WineX has no such a configure switch - with-nptl. So, I'm not sure what are you
talking about.
--
Jason Edmeades [EMAIL PROTECTED] wrote:
Environment
uname -a returns kernel 2.4.21-0.13mdk, and its basically Mandrake Linux
9.1 with no updates. Wine is cvs as of today, configured with --with-nptl
I may be wrong, but according to the information posted to one of our
support forums, support
Mike Hearn [EMAIL PROTECTED] wrote:
Yes, it should also be path normalized, but for some reason I remember
that being more complex than I thought it'd be.
Which function should I use here? There is no strcasecmpW, in shlwapi
there is a function which does that (StrCmpIW or something).
Alexandre Julliard [EMAIL PROTECTED] wrote:
Windows doesn't use SetWindowPos to update the disabled Close button,
but draws the button directly.
Actually that doesn't look right either, we shouldn't bypass the
normal painting code IMO; but RedrawWindow(RDW_FRAME) would probably
work
Mike Hearn [EMAIL PROTECTED] wrote:
Implement a typelib loader cache, minor debug message improvements
+ for (entry = tlb_cache_tail; entry != NULL; entry = entry-next)
+ if (!strcmpW(entry-path, szPath)) {
+ TRACE(cache hit\n);
Shouldn't this be a case insensitive comparison?
--
Dmitry.
Alexandre Julliard [EMAIL PROTECTED] wrote:
This is implemented already in MENU_InitSysMenuPopup; if it doesn't
work right it should be fixed there.
Windows doesn't use SetWindowPos to update the disabled Close button,
but draws the button directly. So you can apply the patch and ignore
only
Alexandre Julliard [EMAIL PROTECTED] wrote:
Actually that doesn't look right either, we shouldn't bypass the
normal painting code IMO; but RedrawWindow(RDW_FRAME) would probably
work better than SetWindowPos.
Here is an updated patch which works for me and also removes
WM_SYSCOMMAND/SC_CLOSE
Alexandre Julliard [EMAIL PROTECTED] wrote:
@@ -1070,9 +1072,10 @@ STATUSBAR_WMSize (STATUSWINDOWINFO *info
width = parent_rect.right - parent_rect.left;
x = parent_rect.left;
y = parent_rect.bottom - infoPtr-height;
-MoveWindow (infoPtr-Self, parent_rect.left,
-
Lionel Ulmer [EMAIL PROTECTED] wrote:
Not really as the code does this :
/* create new subkey name */
new_key_name = _strdupnA(key_name,strlen(key_name)+dkh-keynamelen+1);
if (strcmp(new_key_name,) != 0) strcat(new_key_name,\\);
Robert Shearman [EMAIL PROTECTED] wrote:
e) use strtolW provided by libwine_unicode and declared in unicode.h
In that case should I reimplement _wtol in NTDLL function using strtolW? The
rest of the functions in wcstring.c call their libunicode versions, but this
one doesn't.
No.
Lionel Ulmer [EMAIL PROTECTED] wrote:
It's clearly a bug, since the code asks for trouble by requesting to
read more data than it actually should. In that case the code has to do:
new_key_name = malloc(strlen(key_name)+dkh-keynamelen+1);
strcpy(new_key_name, key_name);
Well, these
Robert Shearman [EMAIL PROTECTED] wrote:
I'd like to get people's opinions on how I should link to the _wtol function
from a Wine DLL. Should I:
a) Link to NTDLL and use the function there
b) Link to MSVCRT and use the function there
c) Create a new function in unicode.h
d) Copy the
Lionel Ulmer [EMAIL PROTECTED] wrote:
The attached patch fixes all crashes on my box, but well, as I am not very
familiar with this code, sent it to wine-devel and not wine-patches for
review by Registry gurus :-)
I'm not a Registry guru by all means :-), but IMO the real bugs are at lines
Jonathan Wilson [EMAIL PROTECTED] wrote:
From looking at microsoft examples, said examples send WM_SIZE to the
status bar and let it reposition itself.
Microsoft examples also tend to be riddled with gotos. I wouldn't use A
Microsoft example did this as justification for anything.
Jonathan Wilson [EMAIL PROTECTED] wrote:
A possibility that status bar will change its size behind your back
justifies the use of GetWindowRect.
ok, good point.
I intend to change it to use GetWindowRect.
But I am going to keep the WM_SIZE stuff in there unless someone can show a
reason
Jonathan Wilson [EMAIL PROTECTED] wrote:
+VOID DIALOG_ShowStatusBar(VOID)
+{
+RECT rcs;
+RECT rc;
+GetClientRect(Globals.hMainWnd, rc);
+Globals.bStatusBarEnabled = !Globals.bStatusBarEnabled;
+if (Globals.bStatusBarEnabled == TRUE)
+{
+
Jonathan Wilson [EMAIL PROTECTED] wrote:
Are the notepad improvements from crossover office going to be merged into
the main wine tree?
They were merged four days ago.
--
Dmitry.
Jonathan Wilson [EMAIL PROTECTED] wrote:
the MS Cards.dll is complled with the dll does the cleanup set to on
(i.e. its using retn xx instructions).
That's how pascal (stdcall) calling convention works.
When I compile it, i get the @nn on the end of the names.
Only native Win32 compilers
Jonathan Wilson [EMAIL PROTECTED] wrote:
Only native Win32 compilers do that. gcc under Linux doesn't generate
that crap.
aah, I was using MingW on windows to test the dll.
You can use Wine build system in order to test your dll. For that you
just need to make your new dll a part of the
Jon Bright [EMAIL PROTECTED] wrote:
will need to do anyway). Wine makefiles already have all the needed
tweaks to strip stdcall @xx suffixes when building under MinGW or Cygwin.
Should I understand from this that Wine should build under Cygwin?
It has some problems (notably for ntdll,
Omer Sahin (Link Bilgisayar) [EMAIL PROTECTED] wrote:
In a CFormView , I create and display a CToolbarDialog. I use DoModal to
display the dialog.
A control (in Parent Windows) 's OnKillFocus event is called AFTER the
child dialog's OninitDialog.
This seems meaningfull to me, but in my
Alexandre Julliard [EMAIL PROTECTED] wrote:
The problem is that you can't depend on it being set, because Wine is
supposed to work fine without it. Setting it in the wrapper script
won't change that, because the wrapper is only used when running from
inside the source tree.
How about the
Alexandre Julliard [EMAIL PROTECTED] wrote:
Define WINEPREFIX if it doesn't exist.
Why do you need that?
I have several Wine trees locally, and start up scripts some of them
set WINEPREFIX to a non default value. In order to avoid setting it
in my ~/.profile I'd prefer that each Wine
Alexandre Julliard [EMAIL PROTECTED] wrote:
I still don't see why you want that, if it's not set Wine will use the
default one already.
Why does wineps complain that it couldn't load %WINEPREFIX%/generic.ppd
specified in the config in the case WINEPREFIX is not set in my environment?
--
Alexandre Julliard [EMAIL PROTECTED] wrote:
Because WINEPREFIX is not set of course. The solution is not to set it
unconditionally, but to fix your config and/or wineps to do the right
thing when WINEPREFIX is not set.
I'm not sure what do you mean by the right thing here. Do you mean that
Alexandre Julliard [EMAIL PROTECTED] wrote:
Well, you cannot use WINEPREFIX in the config file that is in
~/.wine/config, since it can potentially be used without the prefix
being set. The easiest is to replace %WINEPREFIX% by %HOME%/.wine in
that specific config file.
But in order to read
Shachar Shemesh [EMAIL PROTECTED] wrote:
What's the sense in making the accelerators global to all languages?
Each language has it's own accelerator keys (just as it has it's own menus).
I thought that it's better to have them global, until we have them
defined for other languages.
--
Michael Günnewig [EMAIL PROTECTED] wrote:
Adapted it and also added rsrc.res to .cvsignore. So here is the
new resulting patch.
I don't see rsrc.rc in the patch. Also, please send the patch to
wine-patches, since Alexandre doesn't apply patches sent to wine-devel.
--
Dmitry.
Shachar Shemesh [EMAIL PROTECTED] wrote:
As far as I'm concerned, you left out the most important thing WinXP's
notepad does, which is that it is unicode. That's the most important
improvment missing.
Notepad in CX Office was converted to unicode some time ago already.
It has some
Todd Vierling [EMAIL PROTECTED] wrote:
: That's an easy one. One an Alpha, sizeof(int) != sizeof(foo *). I think
: sizeof(int) == 8, while sizeof(foo *) == 4.
Other way round. sizeof(int) == 4; sizeof(void *) == 8.
In that case Wine needs to be compiled with _WIN64 macro defined.
In that
Michael Gnnewig [EMAIL PROTECTED] wrote:
Changelog:
- Implemented Mo* methods in msdmo.dll
- Added stubs for DMORegister, DMOUnregister, DMOEnum, DMOGetTypes,
DMOGetName.
- Added version resources.
Please use a usual Wine scheme for defining version resources,
see existing
Vincent Béron [EMAIL PROTECTED] wrote:
(after a bit more testing)
Using only SUBLANG_FRENCH_CANADIAN will display in French on both
Windows and Wine.
Using only SUBLANG_FRENCH_SWISS will display in English on both Windows
and Wine.
Using only SUBLANG_FRENCH will display in French only in
Vincent Béron [EMAIL PROTECTED] wrote:
W2k here, so this is valid only for it.
LANGIDFROMLCID(GetLocaleThread()) returns 0x0c0c
(FRENCH/FRENCH_CANADIAN) if I don't modify it via SetThreadLocale(), so
I guess that's the default value for that system (equivalent to
LC_ALL=fr_CA).
The results
Marcelo Duarte [EMAIL PROTECTED] wrote:
If I understanded, people that have LANG=fr_CA or pt_PT, etc (non-default
SUBLANG), will have to use English?
If there are no resources with SUBLANGE_DEFAULT, then yes.
Then the correct will be change all resources with SUBLANGE_DEFAULT to
Shachar Shemesh [EMAIL PROTECTED] wrote:
2003-01-05
Shachar Shemesh [EMAIL PROTECTED]
Change the SUBLANG_NEUTRAL clause in all winelib applications to
SUBLANG_DEFAULT, as they should be.
I vote to revert that patch.
Then perhaps I should explain why I submitted this
Shachar Shemesh [EMAIL PROTECTED] wrote:
Then probably you had to replace SUBLANG_NEUTRAL by SUBLANG_DEFAULT
only for LANG_ENGLISH resources. Anyway the patch I just set adds
LANG_ENGLISH,SUBLANG_NEUTRAL to the fallback list, since my test
under win2k shows that.
After some more
Shachar Shemesh [EMAIL PROTECTED] wrote:
That's because there is no resources marked as (LANG_FRENCH,SUBLANG_FRENCH_CANADIAN)
in the Wine apps. If you fairly confident that all flavours of French (including
Canadian) have too little differences and creating separate resources for each
of them
Fabian Cenedese [EMAIL PROTECTED] wrote:
Check out which executable is in the offending region (my guess is it's wine
itself, but it may also be some shared libraries).
Then I guess it's not possible as wine can't relocate itself...
Probably it's another case of some kind of the security
Marcelo Duarte [EMAIL PROTECTED]
I have had some problems with my keyboard, that I discovered recently, reading
the recent discussions.
1) My keyboard is ABNT-2 and in keyboard.c has 2 layouts and I believe that my
keyboard is ABNT-2 with ALTGR but Wine detect it as the first layout
Dmitry Timoshkov [EMAIL PROTECTED] wrote:
Probably it's another case of some kind of the security kernel patch
which marks the area starting from 0x4000 as a not executable stack
and doesn't allow Wine to mmap it.
Of course correct default image base is 0x40.
--
Dmitry.
Marcelo Duarte [EMAIL PROTECTED] wrote:
I used a program that wait a input and out. I pressed ALTGR 1, E (euro),
Delete (with numlock on), numlock, delete (with numlock off) and enter.
After my mail I trying to found the problem, I discovered that the keyboard
accept keys that do not are
Vincent Béron [EMAIL PROTECTED] wrote:
I have problems displaying Wine's app in my locale (fr_CA). They seem to
prefer to go to the English locale, although if launched with
LANG=fr_FR wine notepad
they will obey the French locale.
LANG=fr wine notepad
will display a warning
Vincent Béron [EMAIL PROTECTED] wrote:
I have problems displaying Wine's app in my locale (fr_CA). They seem to
prefer to go to the English locale, although if launched with
LANG=fr_FR wine notepad
they will obey the French locale.
LANG=fr wine notepad
will display a warning about the
biggun from the sun [EMAIL PROTECTED] wrote:
Changelog:
Add a French keyboard layout without Euro.
Why do you need a new keyboard layout? With the new CP_UNIXCP
support in place all the keys should work for you as expected.
Or is it just to suppress a FIXME message? If the latter, I'd
BiGgUn [EMAIL PROTECTED] wrote:
With the new CP_UNIXCP
What is CP_UNIXCP all about ? Is it some kind of translation code mechanism
? I was unable to find any documentation about it.
That's my recently committed patch aiming to avoid problems with keyboard
input in different locales. See CVS
Sylvain Petreolle [EMAIL PROTECTED] wrote:
Even with this added to the source, I dont have Euro key working :
err:keyboard:X11DRV_ToUnicode Please report: no char for keysym 20AC
(EuroSign) :
err:keyboard:X11DRV_ToUnicode
(virtKey=45,scanCode=12,keycode=1A,state=90)
That's a problem with
Sylvain Petreolle [EMAIL PROTECTED] wrote:
I would prefer be able to use my current locale (fr_FR.UTF-8).
Is the RedHat implementation wrong or is it wine ?
I don't know what is wrong, but it's certainly not the Wine problem.
It's a problem with Xlib which couldn't translate EuroSign keysym
to
Sylvain Petreolle [EMAIL PROTECTED] wrote:
I have no problems to type an Euro sign here () and in a terminal. ()
xev does not seem to complain about it :
KeyPress event, serial 25, synthetic NO, window 0x2a1,
root 0x48, subw 0x0, time 6373806, (138,56), root:(339,614),
state
Stephan BEUZE [EMAIL PROTECTED] wrote:
Perhaps we should change FIXME to WARN after some time, when the new
scheme
will be better tested and proved to work in the most cases.
I don't think we can change FIXME to WARN. I presume it was leaved here to
detect new Keyboard Layouts used with
Stephan BEUZE [EMAIL PROTECTED] wrote:
It used to work without FIXME message, why should it suddently give me all
the time this message.
I don't think that it's my patch that caused the FIXME to appear. Could you
try to revert my patch and see whether FIXME goes away?
IMO wine claims
Stefan Jones [EMAIL PROTECTED] wrote:
On upgrading to Wine 20030618/20030709 I found that kazaa lite will no longer
work
...
The following patch reversal fixes it:
( it undoes Dmitry's patch )
If you could confirm that after your patch attached program while loading
native olepro32.dll and
Shachar Shemesh [EMAIL PROTECTED] wrote:
I think I found what is needed in order to implement my suggested
keyboard support. The only drawback is that it requires the use of XKB,
which is not a given in all Xservers. Personally, I find it hard to
believe that there are many X servers that
Shachar Shemesh [EMAIL PROTECTED] wrote:
Actually Alexandre didn't like that patch, and I reworked it and sent to
wine-patches as Add support for CP_UNIXCP. If you could try it and
report whether it allows you to type with UTF-8 locale, it would be nice.
Compiling it as we speak.
I
Shachar Shemesh [EMAIL PROTECTED] wrote:
I get unknown key. I'll try to recompile with it and let you know.
If you have seen that message before, that's normal that it hasn't
disappeared. The patch is not supposed to fix that kind of messages,
it just should use code page associated with
Shachar Shemesh [EMAIL PROTECTED] wrote:
I have been itching to do an overhaul of the Wine keyboard handling for
some time. I think the current scheme is overly complicated, and causes
problems. This is a major task, but I may be able to recrute some local
help. I am a bit worried,
Sylvain Petreolle [EMAIL PROTECTED] wrote:
do you know how to run _all_ tests with verbose output when using 'make
test' ?
What do you mean by a verbose output?
WINETEST_REPORT_SUCCESS=1; make test
will print nice Test succeeded for every test case without errors.
--
Dmitry.
Mike Hearn [EMAIL PROTECTED] wrote:
However, I think it unbreaks InstallShield, which is a fantastically
common application. It might be a case of a lesser of two evils
decision.
Since you don't know what Alexandre means by other things, you
certainly can't compare what evil is lesser :-)
Tom [EMAIL PROTECTED] wrote:
Note, that windows consider Brasilian portugese to be the
default sublang for all portugese:s (which seems to me a bit ackward,
but South America is likely closer to Redmond than Lusitania...)
Same for US English vs. UK English. I was always wondering,
Alexandre Julliard [EMAIL PROTECTED] wrote:
Actually I'm not sure I want to merge that. We really need a proper
fix for the keyboard codepage issue, instead of a UTF8-specific hack.
And what is the proper fix in your opinion? I think that even support
for keyboard layouts won't help for that
Alexandre Julliard [EMAIL PROTECTED] wrote:
And what is the proper fix in your opinion? I think that even support
for keyboard layouts won't help for that particular case.
The proper fix is to determine the codepage from the current locale
information, not from the keyboard layout. This
Shachar Shemesh [EMAIL PROTECTED] wrote:
A while back someone (I think it was Alexander) mentioned something
about UTF-8 working for keyboard detection and entering info. That same
mistyrious someone said it was in XOO, and will be merged when Alexander
finishes his merges.
It was me.
Eric Pouech [EMAIL PROTECTED] wrote:
Note, that windows consider Brasilian portugese to be the
default sublang for all portugese:s (which seems to me a bit ackward,
but South America is likely closer to Redmond than Lusitania...)
Same for US English vs. UK English. I was always wondering,
Tom Wickline [EMAIL PROTECTED] wrote:
Anyone have any
Comments, Flames or Suggestions before I send this ?
Looks good, except the kernel32 API description URL (Kernel-Mode Driver
Architecture). Kernel32 has a lot of function groups, but none of them
has any relationship to kernel mode drivers.
Sylvain Petreolle [EMAIL PROTECTED] wrote:
@@ -1013,7 +1013,8 @@
predefined group index and find it dynamically
Ref: X Keyboard Extension: Library specification (section 14.1.1 and 17.1.1) */
- AltGrMask = event-state 0x6000;
+ /* Save also all possible modifier states. */
+ AltGrMask =
Raphal Junqueira [EMAIL PROTECTED] wrote:
When I try running InstallShield in windowed mode (Desktop = 640x480
as per default in config), window appears for a second and then
dissapears printing this message:
X Error of failed request: BadMatch (invalid parameter attributes)
Major
Arman Aksoy [EMAIL PROTECTED] wrote:
I am posting this mail to you because it was rejected by the mail list
admin .
(It's too big)
Because it's always a good idea to compress large attachments before sending.
armish wine --version
Wine 20030408
armish wine mirc.exe --debugmsg
Arman Aksoy [EMAIL PROTECTED] wrote:
err:module:BUILTIN32_LoadLibraryExA loaded .so but dll display.dll still
not found - 16-bit dll or version conflict.
err:dc:CreateDCA no driver found for DISPLAY
wine: ../../windows/sysmetrics.c:122: SYSMETRICS_Init: Assertion `hdc'
failed.
wine:
Gyrgy 'Nog' Jeney [EMAIL PROTECTED] wrote:
I figured out that the RtlCreateAtomTable function as expecting to get passed
in a NULL as the initial Table, otherwise it thinks that the argument is a
valid atom table and just returns success. This unfourtuneatly makes the test
results that
Gyrgy 'Nog' Jeney [EMAIL PROTECTED] wrote:
Here's the latest version of my RtlAtom test, these should now succeed on
an nt system. Thanks to Dmitry for running the initial test.
There are failures yet.
atom.c:186: Test failed: We found wrong atom
atom.c:232: Test failed: Able to find
Gyrgy 'Nog' Jeney [EMAIL PROTECTED] wrote:
Looking at the ReactOS implementations of RtlAtom* APIs, I've found that
they conform to the results I get under win2k. Did you try to ask a
permission to use their implementation in Wine? Steven?
I don't think that shall be necessary, it looks
Gyrgy 'Nog' Jeney [EMAIL PROTECTED] wrote:
I don't think that shall be necessary, it looks like all that support is in
the wineserver already. It seems like all that is required is to add a
couple of server calls, but I may be wrong.
One more point:
My tests under win2000 show that Windows
KK singh [EMAIL PROTECTED] wrote:
Normally missing GDI32 functions are only called
when using native XP core
dlls (user32, perhaps comctl32, comdlg32 and shell32
) too, which will lead
to other errors too.
KK I am not using any of these in native form...
You *are* using such a dll.
KK singh [EMAIL PROTECTED] wrote:
KK **NEVER** is bit challenging !!!
1. Because atmlib.dll is a user level front end for the kernel level
atmfd.dll.
2. We really don't need to reimplement Adobe Type Manager, we already
have freetype for that task.
P.S.
Could you please try to avoid inserting
Gyrgy 'Nog' Jeney [EMAIL PROTECTED] wrote:
This adds tests for the RtlAtom functions in ntdll. I'm not sure about the
correctness of this patch, so could some people with an nt system run these
and send me the output?
Attached atom.txt is the result of running your test under win2k SP3.
Kevin DeKorte [EMAIL PROTECTED] wrote:
RedHat 8.0 up2date with glibc-2.3.2-4.80
Wine compiles fine, no extra options are needed. But if wine has been built
on the RedHat 8.0 OTB, then you should download a clean source tarball or if
you use CVS, you should delete your working dir and
Tony Lambregts [EMAIL PROTECTED] wrote:
So if I change gdi.h like so and convert PSDRV_StartDoc to unicode I'm home
free yes?
Yes.
--
Dmitry.
Tony Lambregts [EMAIL PROTECTED] wrote:
MultiByteToWideChar uses Rtl* functions internally and using ntdll APIs
directly should give a slightly better performance.
RtlCreateUnicodeStringFromAsciiz also is supposed to hide the internals
of the conversion and help to avoid bugs and
1 - 100 of 437 matches
Mail list logo
