http://bugs.winehq.org/show_bug.cgi?id=3902
------- Additional Comments From giulian2003(a)hotmail.com 2005-01-12 05:47 -------
Great ideea, the code will be cleaner that way!
Anybody knows how can i get this bug assigned to myself?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=3902
------- Additional Comments From julliard(a)winehq.com 2005-01-12 05:26 -------
What you really want to do is implement Get/SetBoundsRect.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=3902
------- Additional Comments From giulian2003(a)hotmail.com 2005-01-12 05:01 -------
It seems that all GDI function have this form:
X11DRV_LockDIBSection/X11DRV_CoerceDIBSection -> X11DRV_DIB_Coerce
Modify DIB or X Server
X11DRV_UnlockDIBSection + sync between DIB and X Server
So, i think the best way to implement the change is to add 4 more implicit
paramenters to X11DRV_LockDIBSection, X11DRV_CoerceDIBSection,
X11DRV_DIB_Coerce, and have the GDI functions eventually pass the rectangle to
X11DRV_DIB_Coerce which will set them into the X_PHYSBITMAP structure.
Something like this:
static INT X11DRV_DIB_Coerce(X_PHYSBITMAP *physBitmap, INT req, BOOL lossy, INT
x=0, INT y=0, INT width=0, INT height=0);
or maybe
static INT X11DRV_DIB_Coerce(X_PHYSBITMAP *physBitmap, INT req, BOOL lossy,
XRectangle *mod_rect=NULL);
The second way would also require for the GDI functions to dinamically allocate
a XRectangle before passing it to X11DRV_LockDIBSection or
X11DRV_CoerceDIBSection so will require a bit more coding. Still not sure which
one is best ...
Anyway, enough talking .. i will try to do the change tonight if i won't be to
tired, and a patch will follow ...
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=3879
------- Additional Comments From jeremielapuree(a)yahoo.fr 2005-01-12 04:01 -------
Hi,
Lionel, to see the intro movies, I had to use Oliver's d3d8-wrapper patch and to
begin to play, I use the mouse_hack patch
Joaopa
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
http://bugs.winehq.org/show_bug.cgi?id=3974
Summary: Fonts are not well displayed
Product: Wine
Version: 0.9.2.
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-user
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: curritoamores(a)hotmail.com
I have an acces 97 app and i want to view some reports. The problem is that for
some of them fonts are not well displayed.I have copied all the fonts from
windows. But this problem is only with two or three kinds of reports, some of
them are well displayed.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=3967
------- Additional Comments From tuharsky(a)misbb.sk 2005-01-12 01:35 -------
Please, note that:
1, Until now, there isn't native odbc backend in wine, although requested more
than 3 years ago.
2, There is a way to enable it, using native ODBC dll's (from myODBC 2.5
installation), that even WORKED WELL until 200505 version of Wine (see 3966).
3, This is the only way to run free Oracle client with apps under wine, because
Oracle dosen't support ODBC driver for Linux.
4, Wine indeed IS about making native DLL's work too, especially if they aren't
implemented by wine. If it wasn't, hardly could any slightly more complex app
work. Nice example: it is even adviced to use common controls native DLLs
sometimes. And they are even implemented! So much more should Wine care about
handling those DLL's that aren't implemented either. Especially those that are
essential to run apps.
"Wine is an Open Source implementation of the Windows API". Logically, if the
API is implemented correctly, the DLL's should work too, don't they?
5, Since yesterday, under my closer inspections, this bug seems to be not about
odbcad32.exe itself, but rather about the very ODBC libraries under wine.
Even if it was just about odbcad32.exe, what's wrong about it if it was
necessarry to run app under wine? The DB sources must be defined somehow, and
odbcad32.exe is good way to do it.
Eventually, it is stil all about compatibility with Window$...
If You be so kind and wish to help us with problem 3966 that puts our Linux
installations under danger, then odbcad32.exe is good way to test the native
ODBC libraries behaviour. If they worked well with odbcad32.exe, then they will
surely work with our very essential app.
If my expectations are right, than this issue could be marked as duplicate of
3966. What do You suggest?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=3636
leon-winebus(a)cyberknights.com.au changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |leon-
| |winebus(a)cyberknights.com.au
------- Additional Comments From leon-winebus(a)cyberknights.com.au 2005-01-12 00:12 -------
Had to change assert.h and stdlib.h from "" to <> to make Dan's patch compile on
Mandriva 2006.0, but it does build against their 0.9.2 source RPM.
I too had to lie to the installer about having MSIE before it would run (thanks
for this, Dan!):
cat >> $HOME/.wine/system.reg <<"_EOF_"
[Software\\Microsoft\\Internet Explorer]
"Version"="6.0.2900.2180"
_EOF_
--- CAUTION: DIGRESSION ---
Dan, your initvbapp.sh seems to have a microbug: you fetch and unpack unshield,
then (re)assign $CABEXTRACT to it, then later use unshield instead of what I
think you wanted to do, which was use $UNSHIELD which in turn I think you wanted
to assign from `pwd`/src/unshield.
Also, Mandriva includes cabextract and unshield in their packaging system; you
can test for the existence of it there by checking the status of "urpmq
packagename", and install it (as root) with "urpmi packagename". It might be
generally handy to have a utility script available on every new system, one that
you pass a wanted package name to, which finds out where it is running (Debian,
SuSE, Mandriva, Slack, whatever) and installs the packages if they're available
through the package system or returns false if it can't. I dub it mayihave, so
you'd invoke "mayihave cabextract" and revert to download/unpack/configure/make
only if that fails.
--- END DIGRESSION ---
The result with MDAC 2.7 [*** MY COMMENTS LIKE SO ***] is:
fixme:advpack:IsNTAdmin (0x00000000, (nil)): stub
fixme:setupapi:SetupScanFileQueueA stub
fixme:setupapi:SetupScanFileQueueA stub
fixme:setupapi:SetupScanFileQueueA stub
fixme:setupapi:SetupScanFileQueueA stub
fixme:setupapi:SetupScanFileQueueA stub
fixme:setupapi:SetupScanFileQueueA stub
fixme:setupapi:SetupScanFileQueueA stub
fixme:setupapi:SetupScanFileQueueA stub
fixme:setupapi:SetupScanFileQueueA stub
fixme:setupapi:SetupScanFileQueueA stub
fixme:setupapi:SetupScanFileQueueA stub
fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub
fixme:richedit:RichEditANSIWndProc EM_LIMITTEXT: stub
[*** CLICK ON LICENCE AGREEMENT HERE ***]
fixme:setupapi:SetupAddInstallSectionToDiskSpaceListA Stub
fixme:setupapi:SetupAddInstallSectionToDiskSpaceListA Stub
fixme:setupapi:SetupAddInstallSectionToDiskSpaceListA Stub
fixme:setupapi:SetupAddInstallSectionToDiskSpaceListA Stub
fixme:setupapi:SetupAddInstallSectionToDiskSpaceListA Stub
fixme:setupapi:SetupAddInstallSectionToDiskSpaceListA Stub
fixme:setupapi:SetupAddInstallSectionToDiskSpaceListA Stub
fixme:setupapi:SetupAddInstallSectionToDiskSpaceListA Stub
fixme:setupapi:SetupAddInstallSectionToDiskSpaceListA Stub
fixme:setupapi:SetupAddInstallSectionToDiskSpaceListA Stub
fixme:setupapi:SetupAddInstallSectionToDiskSpaceListA Stub
[*** CLICK ON FINAL DIALOGUE "Finish" HERE ***]
fixme:advpack:LaunchINFSectionEx (0x2002e 0x1000000
"C:\\windows\\temp\\IXP000.TMP\\rspfiles.inf,DefaultInstall.NT,,0,N" 0): semi-stub
fixme:advpack:LaunchINFSectionEx (0x2002e 0x1000000
"C:\\windows\\temp\\IXP000.TMP\\dasetup.inf,DefaultInstall.NT,,0,N" 0): semi-stub
fixme:advpack:LaunchINFSectionEx ((nil) (nil)
"C:\\windows\\temp\\IXP000.TMP\\\\MDACXPAK.INF,DefaultInstall,,32,N" 0): semi-stub
fixme:advpack:LaunchINFSectionEx dwFlags: Backup data before install
fixme:setupapi:extract_cabinet_file awful hack: extracting cabinet
"C:\\windows\\temp\\IXP000.TMP\\MDACxpak.CAB"
fixme:advpack:ExtractFiles (0x7fe56d10 0x7fe56ce8 0x00000000 (nil) (nil)
0x00000000): semi-stub
err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to
dispatch exception.
Cheers; Leon
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=3967
------- Additional Comments From vitaliy(a)kievinfo.com 2005-30-11 20:18 -------
Sorry, but Wine is not about making native dlls (or other parts of OS) work. So
in other words I don't see anything here that doesn't duplicate bug 986 (that
pretty much means Wine does not have anything implemented in this area).
dbcad32.exe is part of windows and not your application.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.