Ove Kaaven [EMAIL PROTECTED] wrote:
Some problems that I tried to solve:
1. I didn't find way to make to work XLookupString with setlocale(LC_CTYPE,"").
I don't know exactly how this works, but what is your locale settings? I
know that glibc and Xlib disagrees somewhat on the format of the
Ove Kaaven [EMAIL PROTECTED] wrote:
Gerard is from France. French keyboards don't have a QWERTY layout, they
have AZERTY. I suspect Gerard just got the key reassigned to W...
Ah! It expalains all of it! I should notice it earlier by examining more
carefully the keyboard layouts (particularly
"Alexandre Julliard" [EMAIL PROTECTED] wrote:
I think it's reasonable to give the native dll priority when doing
LOAD_LIBRARY_AS_DATAFILE. An app using this wants to poke inside the
dll binary file and we are much better off giving it the 'real' thing
in this case IMO.
Perhaps version.dll
"Alexandre Julliard" [EMAIL PROTECTED] wrote:
I think it would be better to keep the existing support for native
dlls, and simply fall back to loading the builtin library if
SearchPath fails.
Does the attached patch look as applicable?
module.c.diff
Andreas Mohr [EMAIL PROTECTED] wrote:
...
- better WM_GETDLGCODE
Why were Wine's values so completely different from the MS documented
ones ??
Hello.
This patch will break the recently fixed accelerators in dialogs,
because of code in dialog.c relies on the fact that dlgCode returned
by
Alexandre Julliard [EMAIL PROTECTED] wrote:
ChangeLog:
Implementation of RtlUnicodeToMultiByteN, RtlUnicodeToOemN,
RtlOemToUnicodeN, RtlMultiByteToUnicodeN using internal tables.
I don't think building the tables at run-time is a very good idea. It
eats lots of memory, and the way you
Ove Kaaven [EMAIL PROTECTED] wrote:
I didn't understand yours "it is impossible to have two Unicode chars map
to the same ASCII value". Would you say it more popular please?
Example:
002D;HYPHEN-MINUS;Pd;0;ET;N;
00AD;SOFT HYPHEN;Pd;0;ON;N;
2010;HYPHEN;Pd;0;ON;N;
Alexandre Julliard [EMAIL PROTECTED] wrote:
Ove Kaaven [EMAIL PROTECTED] writes:
Well, the SBCS codepage NLS files, yes. The other files (toupper/tolower
in l_intl.nls, which I did figure out recently by looking at YAW sources,
the locale files, and especially the sorting tables, which is
Ove Kaaven [EMAIL PROTECTED] wrote:
Can't data for X11 encodings just be internal to x11drv?
Are the X11 encodings such specific and can not be replaced by the standard
encodings? Having such common feature as support for various encodings in one
place (kernel/ntdll) should help to
Hello again.
I ended writing a program that generates nls-like files from txt files
at unicode.org. Ability to have aliases for translation from the multiple
unicode chars to a single code page char as suggested by Alexandre included.
But now the following problem is appeared. Either my program
Juergen Schmied [EMAIL PROTECTED] wrote:
Hi!
Does anybody knows this functions? I found only documentation for
the subfunctions 1-4.
Looks like a show stoper for outlook97.
From Ralf Brown's Interrupt List v. 6.0:
==
215F44N - LAN
Ove Kaaven [EMAIL PROTECTED] wrote:
[...]
Why should they not use the existing infrastructure and Win32 API? Isn't
it reasonable to expect them to use RtlCustomCP routines with whatever
encoding tables they like?
[...]
ISO issues standards, MS doesn't. Unicode publication is for convenience.
But
Patrik Stridvall [EMAIL PROTECTED] wrote:
[...]
winapi_check currently does rudimentary checks like.
1. Every Windows API function must have a documention header.
2. The documentation header must contain the function name
in some form.
How about to check prototypes of API functions in the
Francois Gouget [EMAIL PROTECTED] wrote:
[...]
It doesn't matter, whether "the real" GetFullPathName leaves forward
slashes or not. This behaviour is "implementation specific".
One could also argue that it maybe it's the documentation which is
incorrect/incomplete in that it does not say
gerard patel [EMAIL PROTECTED] wrote:
Bug report : Eudora 3.06 Light hangs after displaying its main window;
there is no crash, just an infinite loop. This occurs only in -managed
mode. The following change is responsible:
[...]
Since the change was done today, it seems possible this time to
Dimitrie O. Paun [EMAIL PROTECTED] wrote:
[...]
I think we should be a lot more agnostic about the string encoding. What I
mean is that we should have only one function that works with all encodings,
which takes as the first argument the encoding used by the other strings
passed in as arguments:
Dimitrie O. Paun [EMAIL PROTECTED] wrote:
But this transition will consume a lot of time and efforts, because
currently Wine does all work in reverse order.
Yes, but once we set up a pattern, we can have a gradual transition.
Along with transition to internal unicode implementation, I think
Hello all.
Have a look at http://members.xoom.com/EliCZ/import.htm
about API spying in NT and Win95.
Some other documents might be interesting too.
Dmitry.
Jeremy White [EMAIL PROTECTED] wrote:
Given the amount of progress Wine has made over the past year,
it seems (to me anyway) that the time may be appropriate to
try for Wine version 1.0.
I was hoping to spark a conversation on this topic, in two basic areas:
1. Should we do it? (If not,
James Sutherland [EMAIL PROTECTED] wrote:
I don't think it's worth internationalizing the TRACE/WARN/ERR at
this point. I think we should focus on making sure the user sees as
little of them. But then, if someone really wants to take on this huge
task...
I'm going to need similar
James Sutherland [EMAIL PROTECTED] wrote:
I would suggest to use FormatMessage() API instead of inventing new
interface. You even could add new error codes if you wish to extend
an existing functionality.
Which API is that? It looks like a Win32 one from here, which tends to
suggest I can't
Alexandre Julliard [EMAIL PROTECTED] wrote:
I thought it would be easier to just convert them to the macros
and only then gradually move to WideCharToMultiByte/MultiByteToWideChar.
I don't think converting them to macros gains anything. We can just
leave them as functions and move gradually
Marcus Meissner [EMAIL PROTECTED] wrote:
+ /*Now we should know screen size. */
+ hWnd = GetDesktopWindow();
+ wndPtr = WIN_FindWndPtr( hWnd );
+
+ if( hWnd )
+ {
+ GetClientRect( hWnd, DesktopRect );
+ }
+
+ WIN_ReleaseWndPtr( wndPtr );
What strange hack is this? Why does it
Sam Dennis [EMAIL PROTECTED] wrote:
I've wanted to get into wine development for some time now but I've never
found a bug simple enough for me to comprehend (and, normally, that everyone
else hasn't already found ten times over), let alone fix. I really want to
contribute something to the
Joerg Mayer [EMAIL PROTECTED] wrote:
Print full ansi char set (from 32 to 255), not only from 32 to 126,
print other values in hex.
Umm, would that print the characters from 128 to 128+31 too? If so,
I don't think that should be done.
I don't know what do you mean by "128+31".
admiral coeyman [EMAIL PROTECTED] wrote:
Print full ansi char set (from 32 to 255), not only from 32 to 126,
print other values in hex.
Umm, would that print the characters from 128 to 128+31 too? If so,
I don't think that should be done.
Actually, there are no ansi characters
michael cardenas [EMAIL PROTECTED] wrote:
[...]
also, a number of users say then when they bring up the common dialogs,
they just flicker their focus rapidly and nothing can be done. You can see
some of this discussion at:
Hello all (mostly Ove).
I would like to know what criteria is currently used to show
current percentage of Wine completeness. These are just magic digits
for (not only) me now.
I think that having some sort of "to do list" for every "Aspect or
Component" would be very helpful thing. Everyone
Ove Kaaven [EMAIL PROTECTED] wrote:
I doubt you can get the Unicode state to 100% in just a few weeks...
but in case it is of interest, I have written UTF-8-Unicode conversion
routines in another project, and I could probably 'donate' them to the
Wine project, if someone else wants to integrate
Alexandre Julliard [EMAIL PROTECTED] wrote:
Perhaps a cleaner way will be to convert
(*pSetText) driver function to unicode, convert WND.text to LPWSTR
and localize this hack to x11drv only?
That would be much better yes. We don't want the actual window text to
be mapped, only what we pass
TAKESHIMA Hidenori [EMAIL PROTECTED] wrote:
[...]
Now I modify X11DRV to support DBCS.
[...]
Hello.
Is it really needed to introduce new hacks for DBCS support?
Wine now have support for code pages including DBCS.
- str2b_dst-byte2 = str[i];
- if (IsDBCSLeadByteEx( codepage,
Ove Kaaven [EMAIL PROTECTED] wrote:
3. How support for DBCS charsets is implemented in libc and X?
We should not depend on libc... its locale system is very independent of
X's (and only glibc2.1 supports locales well, glibc2.0 didn't).
I just wanted to know how libc and X manage DBCS (without
Susan Farley [EMAIL PROTECTED] wrote:
This patch to combo.c selects the text in the edit control
when the control gains (or is created with) focus, and
deselects it when focus is lost.
log: select/deselect text in edit box on focus gain/loss
Selecting/deselecting text in an edit box while
Hello all.
Here is my new attempt on fixing FindResource(Ex).
I'm sending it here for review, testing and feed back.
To all interested parties: Please try it and report back.
Actual patch: include.diff, loader.diff.
See my comments in loader.diff.
test.zip is my test suit for testing of
Peter Ganten [EMAIL PROTECTED] wrote:
Unfortunately, I get the same results with this patch as with your
last one. When starting Winword (german version, from office 97), WINE
complains about undefined locale information:
fixme:string:GetLocaleInfoA 'SLANGUAGE' is not defined for your language
Hello all thunking gurus out there.
Can somebody help with this PageMaker crash?
...
Call kernel32.601: SMapLS_IP_EBP_8() ret=006f8e0f fs=008f
eax= ebx=410e3ac0 ecx=40333b64 edx=065e esi=067f edi=067f
ebp=409d6340 esp=409d62f8 ds=002b es=002b gs= flags=0212
Ret
Peter Ganten [EMAIL PROTECTED] wrote:
Looking into wine/dlls/kernel/nls directory, you could notice that
041f is an identifier for Turkish locale (trk.nls), and it of course
don't define SLANGUAGE. So, the message is true. You should in this
case either define it as suggested by the
Peter Ganten [EMAIL PROTECTED] wrote:
The application is Winword from Office 97, german version. It does,
what this short program illustrates:
[...]
hRes = FindResourceEx ( hMod, (LPCTSTR )0x2, (LPCTSTR )0x1c85, 0 );
Ah, of course! Made another test and found: FindResourceEx with lang = 0
Uwe Bonnes [EMAIL PROTECTED] wrote:
Matthias Bleyl writes:
Hi,
I tried to run wincommander ("http://www.ghisler.com/index.htm") on wine.
This works not too bad. However, there are a lot of error messages. I run
wine-2716 on SuSE6.4.
(Some) error messages I get:
Warning: language
Hello all.
Here is an experimental version of my new language detection scheme.
It uses Wine NLS data base instead of hard coded values.
All suggestions will be appreciated.
Dmitry.
ole2nls.c.diff
Hello.
Decided to move to the newest CVS, and ...
Some of the modifications to PE loader broke PageMaker:
...
Call kernel32.495: LoadLibraryA(408866b8 "C:\\Adobe\\pm65\\RSRC\\USENGLSH\\PM65.RSL")
ret=006340b1
fs=008f
trace:module:MODULE_GetLoadOrder looking for
Hello.
This patch broke correct displaying of cyrillic characters:
revision 1.28
date: 2000/08/20 20:08:35; author: julliard; state: Exp; lines: +20 -14
Hidenori Takeshima [EMAIL PROTECTED]
Handle the codepage of fonts if supported by the graphics driver.
because of:
1. My app loads
Francois Methot [EMAIL PROTECTED] wrote:
For the transparency issue, this patch implement a switch-case for the
bitcount (bit per pixel) of the animation files. With this switch different
line of code is executed for getting and setting the transparency color
whenever it's 2, 4, 8, 16, 24 or 32
Francois Methot [EMAIL PROTECTED] wrote:
This patch prevent a system menu from appearing on a docker by filtering the
Style and ExStyle of a window.
The system menu won't be displayed if a given window has the following
style:
WS_EX_TOOL_WINDOW
However to display it, it requires those:
Alexandre Julliard [EMAIL PROTECTED] wrote:
2. Then app displays the text using ExtTextOutA. Here the problems begin.
Now ExtTextOutA assumes, that ANSI code page and code page of currently
selected font is the same. It is wrong assumption. As it was many times
pointed out (at least by me).
Alexandre Julliard [EMAIL PROTECTED] wrote:
I don't have any Russian fonts on my Windows machine to test this, but
if I select an OEM font TextOut definitely uses the OEM codepage, not
the CP_ACP one. So we cannot assume that all strings passed to TextOut
are in current ANSI codepage; we have to
TAKESHIMA Hidenori [EMAIL PROTECTED] wrote:
I check original windows 98(Japanese edition; CP_ACP=cp932).
There are some system fonts that have codepage CP_ACP
(at least in my environments):
- System, FixedSys, Terminal
Probablly, these three 'reserved' fonts should be treated
as special font
Alexandre Julliard [EMAIL PROTECTED] wrote:
"Dmitry Timoshkov" [EMAIL PROTECTED] writes:
Changelog:
Small correction for path stripping.
This breaks paths that contain both '/' and '\'. What are you trying
to fix?
Well, while I searched for a real culprit of crash with prin
Alexandre Julliard [EMAIL PROTECTED] wrote:
BUILTIN32_dlopen seems correct to me. Are you sure the problem wasn't
rather with BUILTIN32_LoadLibraryExA? We don't try to handle '/'
there, and maybe we should (but it has to be done the same way as in
BUILTIN32_dlopen, not the way you did it in
Hello all.
I'm still trying to solve problems with PageMaker and thunking...
Assuming, that problems arise with using QT_Thunk/SMapLS_IP_EBP_8/SUnMapLS_IP_EBP_8
functions (i.e. Win95 thunks), I guessed that -winver nt40 will solve at least some
part of the problem. But PM always used Win95
gerard patel [EMAIL PROTECTED] wrote:
[big snip]
If other had similar experiences, it would probably a good thing
to include in the how-to or faq that while Wine will work
correctly for most programs with glibc 2.0, it works best with
glibc 2.1 (apart from the infamous Redhat 2.1.3 problem, of
Ulrich Weigand [EMAIL PROTECTED] wrote:
I've now modified the CallTo16Register routines to save (some) register
values possibly modified by the called 16-bit routine back into the
CONTEXT86 structure. Saving *all* registers is difficult (or at least
would create more overhead), so I decided to
Hello all.
Some traces +mdi and version of strlenW that prints result
before exit:
...
trace:mdi:MDI_UpdateFrameText AFTER lstrcpyW(lpBuffer): L"Adobe PageMaker 6.5"
trace:mdi:MDI_UpdateFrameText BEFORE strcatW(L"Adobe PageMaker 6.5", L" - [")
strlenW(): 19 -- right
Hello all.
The question is short: is EnumResourceTypes supposed to work with
16-bit modules?
I ask because I don't know what to do: simply avoid crashing by
checking HIWORD(hModule), or implement a full working solution.
Dmitry.
Hello all.
My app have a problem with repainting its menu in managed mode.
Funny, but it can be reproduced with old 16-bit clock.exe
from windows 3.1.
How to reproduce: Double clicking on the client area switches
clock modes: with menu (and caption) and without menu (and caption
in not managed
gerard patel [EMAIL PROTECTED] wrote:
[...]
If I test this patch with winedt (available from www.winedt.com), my
X-server crashes when I try to load the Options dialog box. Winedt is a
program written in Delphi I think; Borland has a very special system to
simulate modal dialog boxes; I see
gerard patel [EMAIL PROTECTED] wrote:
If I test this patch with winedt (available from www.winedt.com), my
X-server crashes when I try to load the Options dialog box. Winedt is a
program written in Delphi I think; Borland has a very special system to
simulate modal dialog boxes; I see the same
gerard patel [EMAIL PROTECTED] wrote:
[...]
I investigated further, without great success.
It's difficult to trace since the end of the trace disappear, I ended up adding
a sync() call at this point. What happens is that the main window (the one being
disabled) get an UnmapNotify event almost
James Hatheway [EMAIL PROTECTED] wrote:
I don't think your patch is causing these problems. I have these two same
Balsam for my soul...
problems in the app that I am debugging, without your patch applied.
(I get this problem with KDE 1.1.2) For me, when the app starts up
it has a normal
mark dufour [EMAIL PROTECTED] wrote:
Here's another implementation, for the PolyDraw function. Like AngleArc, this
is NT-only. I installed NT for the occasion and tried out all possible
situations I could think of. I also found a bug in my AngleArc
implementation, so I'm submitting that
TAKESHIMA Hidenori [EMAIL PROTECTED] wrote:
ChangeLog:
dlls/comctl32/datetime.c
dlls/comctl32/header.c
dlls/comctl32/rebar.c
dlls/comctl32/status.c
dlls/comctl32/toolbar.c
dlls/comctl32/treeview.c
dlls/commdlg/filedlg.c
dlls/shell32/shlfolder.c
dlls/shlwapi/path.c:
fix for supporting
Okay, things are simpler than they look.
Eyes are afraid - hands are doing (russian byword).
I have wrote a very simple sample that demonstrates bitmaps
in the menu (mono and 16 colors, you can add your own of course).
Selected color bitmaps are inverted in both win95 and win98,
but monochrome
Ove Kaaven [EMAIL PROTECTED] wrote:
The first crash in civ2 that I didn't have a patch for goes like this:
First, it creates (hidden) windows and stuff, and
Call USER.100: DLGDIRLIST(0x01bc,0x07771dca "*.*",0x0064,0x,0x4000) ret=03e7:0ed8
ds=0777
... (DDL_DRIVES)
Ret USER.100:
windows: message.c winproc.c
Log message:
Dmitry Timoshkov [EMAIL PROTECTED]
Added mapping to/from unicode for WM_CHAR, WM_DEADCHAR, WM_SYSCHAR,
WM_SYSDEADCHAR messages.
Patch:
http://cvs.winehq.com/patch.py?root=/opt/cvs-commitlogs=/opt/cvs-commit/CVSROOT/winecommitlogid=97
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Thu, 16 Nov 2000, Dmitry Timoshkov wrote:
Hello.
Changelog:
Dmitry Timoshkov [EMAIL PROTECTED]
Always generate unicode CHAR messages.
Good day!
This broke my mail app. I have been running with it 'til now, so I
guess you could say
Jon [EMAIL PROTECTED] wrote:
I'm having a problem implementing locale related functionality for crtdll.
Basically, I need to get an LCID from a locale string, rather than from a
locale id as used by the MAKELCID macro.
Which crtdll function does need this?
There doesn't appear to be a way to
Nerijus Baliunas [EMAIL PROTECTED] wrote:
Sorry, I didn't know that. I thought it is/was the same [EMAIL PROTECTED]
Updated patch:
[...]
-Patches should be submitted to "[EMAIL PROTECTED]". Please don't
+Patches should be submitted to "[EMAIL PROTECTED]". Please don't
Do you know that to post
"Alexandre Julliard" [EMAIL PROTECTED] wrote:
GlobalAlloc/GlobalReAlloc: Make allocations with granularity 32
bytes.
Clear error on success in GlobalLock as Windows does.
What version does this? NT 4 definitely doesn't set last error on
success (and it doesn't seem to round up the
"Alexandre Julliard" [EMAIL PROTECTED] wrote:
I got this results running my test app that creates unicode and ansi edit
controls
and dumps their contents. Memory blocks are always 32-byte aligned.
Couldn't this be because the edit control does the rounding?
I made another test and it
"gerard patel" [EMAIL PROTECTED] wrote:
[...]
- in X11DRV_IsClipboardFormatAvailable a call to
CLIPBOARD_IsPresent had disappeared; adding it again
get back the text exchange between Wine applications.
X11 clipboard driver should call only exported win32 functions IMO.
Driver doesn't need
"gerard patel" [EMAIL PROTECTED] wrote:
Do you have an unicode version of listbox in the works ?
Yes, I'm working on it right now. After a general way of testing
I'll send it to wine-patches.
Since the combobox is unicode, cb_findtext* apis
seem to have problems; I think it should not
"gerard patel" [EMAIL PROTECTED] wrote:
Do you have an application that doesn't work after the edit control rewrite?
Notepad 16 bits. The version I use for testing was coming with Wfw 3.11 I think.
I have searched a bit and the problem seems to be the buffer length.
The problem is that
"gerard patel" [EMAIL PROTECTED] wrote:
Please try this patch (I have no 16-bit notepad):
snip edit patch
I have tested it a bit, it seems to work fine as long as I edit text and
use disk access; I have tried clipboard (pasting text from the clipboard
into Notepad 16) and it was not
This patch works fine for me. Could you please test it too?
--- cvs/wine/controls/edit.cFri Jan 5 15:21:35 2001
+++ wine/controls/edit.cTue Jan 9 22:13:46 2001
@@ -1482,25 +1482,22 @@
}
if (!es-text) {
CHAR *textA = NULL;
- INT countA = 0;
+
"gerard patel" [EMAIL PROTECTED] wrote:
While your patch makes the scrolling behaviour of the edit control better,
are you sure you could not get the same effect without this change ?
Yes, all works fine with this line in place. Alexandre, please ignore this
one-liner change for scroll.c. Or
"gerard patel" [EMAIL PROTECTED] wrote:
Wait, there is at least another problem with this patch.
It's about the access to the edit's parent control. Try this
with your patch : use any 32 bit program (I tested with
the Word 97 viewer, this happens also with Forte Free
Agent32) to open a
"gerard patel" [EMAIL PROTECTED] wrote:
Could you please add
if(!(es-style ES_MULTILINE)) return;
at the start of EDIT_UpdateScrollInfo and try that patch again?
Yes, it works with this change; this is not surprising, do you intend
this as a test or as a real fix ?
It was suggested
Hello all.
While working on the problems with scrolling in the 16-bit notepad,
I tried to avoid loading file via File-Load-etc, but use command line
instead: wine -debugmsg +edit,+scroll notepad -- new.txt ~/notepad.log.
Unfortunately notepad seems to not correctly understand its command line
"Francois Gouget" [EMAIL PROTECTED] wrote:
Well, I'm not in France but I do sometimes use my qwerty keyboard in
'US-International' mode so that I can get some of these French
characters... via dead-keys. Of course it seems like half the Unix
applications don't support dead keys and the
Ove Kaaven [EMAIL PROTECTED] wrote:
[skipped]
2. Accent characters in different code pages has different mappings to
unicode characters. Perhaps we just have to create internal table with
mapping [combining character in code page] - [combining character in unicode]?
Since the last deadkey
Ove Kaaven [EMAIL PROTECTED] wrote:
Sure, X11 should do it for us. Hints, please: what X11 dead-key stuff?
That's a good question. I don't really know, and don't have time to read
the Xlib manual right now (have to catch a flight in a few hours), but I
suspect it might have something to do
Hello all.
Some time ago, when I was testing standard USER controls with the new unicode
stuff, I encountered the following problem not related to controls at all.
One of my test applications is Adobe PageMaker 6.5. It loads its plugins and
initializes menu with strings loaded from the plugin
"Joao clemente" [EMAIL PROTECTED] wrote:
I was thinking of changing the keybord settings in X11 so that I try to find
out something else about this matter...
Do you think it's worth triying? ( lame question : I do that in Xf86config
file, right?)
Btw... do you think I can read some
Joao clemente [EMAIL PROTECTED] wrote:
...
: 2. There are two approaches in implementing support for DK:
: a. Do all the character composing in Wine itself, completely ignoring X.
You mean, having to write something like those tables that exist to handle
the keyboard?
Not at all. Those tables
Gavriel State [EMAIL PROTECTED] wrote:
It's at http://opensource.corel.com
It hasn't been updated in quite a while, and the last import from
WineHQ was back in December '99, I believe. In addition to the
font/printing work, there may still be a few other outstanding fixes
that haven't made
"Francois Gouget" [EMAIL PROTECTED] wrote:
rant
I checked the other cases and I have this question. Why does everyone
use 0 instead of '\0', 0 instead of FALSE, and '\0' instead of NULL? MS
even does the reverse and uses NULL in places where '\0' or 0 would have
been more appropriate. Man,
"Ian Pilcher" [EMAIL PROTECTED] wrote:
+
+/*
+ * The Win32 doc says that RegCloseKey and HeapFree can fail, but it's hard to
+ * imagine why either of them would. And what is the calling function supposed
+ * to do about it anyway?
+ */
+
+#define REGCLOSEKEY(X) \
+{ \
+DWORD ret;
"gerard patel" [EMAIL PROTECTED] wrote:
As it's rather unlikely anyone will craft 16 bits specific resources now, I have
mapped the 32 bits resource into 16 bit ones
I did not test if 16 bits printing still works, but the print dialog box displays
again
at least.
There is also a minor fix
"Andreas Mohr" [EMAIL PROTECTED] wrote:
That hack cured the application, but Andreas
Well, that's not exactly true.
You did not do it "for edit control". You did it for *all* controls
in DIALOG_GetControl16() (at least in the patch you sent me).
That's why I objected. I just had to :)
"gerard patel" [EMAIL PROTECTED] wrote:
ChangeLog:
* dlls/comctl32/rsrc.rc
Add version info.
[...]
LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
+
+1 VERSIONINFO
+FILEVERSION 4, 72, 0, 0
+PRODUCTVERSION 4, 72, 0, 0
+FILEFLAGSMASK VS_FFI_FILEFLAGSMASK
+FILEOS
"gerard patel" [EMAIL PROTECTED] wrote:
Getting the common controls to the 4.72 version at least is the *whole*
purpose of the patch. There are applications testing the version number of the
common controls - tons of them : all the apps written with modern
Borland tools. Their behaviour
[EMAIL PROTECTED] wrote:
Now the question: How to load built-in dll without resolving its imports?
Where's the harm in resolving the imports of the builtin?
In this case, the app has already loaded and used oleaut32 before it
gets around to asking about its version.
If the dll already
[EMAIL PROTECTED] wrote:
Strange, I tested my patch with About.exe and it worked for me.
From the trace you sent me directly my patch works just fine.
You could try replace version.rc by the following version resource, and
to see if it will help (even better try to use both and report
[EMAIL PROTECTED] wrote:
Nuts! Parse errors still, until I added
VS_VERSION_INFO VERSIONINFO
before it, then it compiles clean, but all values except Translation are
null. So I tried with this dlls/oleaut32/version.rc, and it works (if
you get this letter):
#define WINE_FILEVERSION
[EMAIL PROTECTED] wrote:
Could you please experiment some more and try to replace 2,20,4054,1 and
"2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that
numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and
so forth?
Okay. 2.20.4054 is the
[EMAIL PROTECTED] wrote:
Could you please experiment some more and try to replace 2,20,4054,1 and
"2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that
numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and
so forth?
Okay. 2.20.4054 is the
[EMAIL PROTECTED] wrote:
I guess it doesn't look at all of it though. I will try later with
2.20.4055 if this is a minimum or it wants the one it installed.
It likes 2.20.4055, and 2.21.4053, but turns up its nose at 2.20.4053,
so I guess 2.20.2054 is its minimum oleaut32.
Will you
[EMAIL PROTECTED] wrote:
I guess it doesn't look at all of it though. I will try later with
2.20.4055 if this is a minimum or it wants the one it installed.
It likes 2.20.4055, and 2.21.4053, but turns up its nose at 2.20.4053,
so I guess 2.20.2054 is its minimum oleaut32.
Will you
[EMAIL PROTECTED] wrote:
Could you please experiment some more and try to replace 2,20,4054,1 and
"2.20.4054" to the something more simple: 2,0,0,0 and "2.0". If with that
numbers juno will not work 2,1,0,0 and "2.1", then 2,2,0,0 and "2.2" and
so forth?
Okay. 2.20.4054 is the
[EMAIL PROTECTED] wrote:
I just don't like an idea to hunt down all that cases when some application will
want
that strange version numbers. Will 10.0 work for you?
Yes. I can't promise it will work for other apps, and maybe in time we
will have to go to "255.0" or something, but for
1 - 100 of 437 matches
Mail list logo
