The Windows api method uses the function call IDvdInfo2::GetDiscID
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c…
This returns a unique 64bit ID for a DVD.
Has anyone found out what exactly it does to create this 64bit ID.
It would be nice to get linux DVD players to be able to use the same method.
Cheers
James
( I have posted a similiar question in wine-users,
don't flame me for doing so, just thinking about this
some more, perhaps it may be more a developer question
)
Ok, I have a windows app, that runs under wine fine -
not quite. This app has a form, with many text field
edit boxes on. Quite often these edit boxes already
have text values, ie. they are not empty - there is a
database behind the form.
Anyway, the form shows on the screen, but the text
within the edit fields is invisible, until you
activate each edit box component. When you leave one
edit box to the next, the text remains visible.
It seems like the repainting is not working, on
initial startup of the form.
As a way to debug this database app ( I don't have the
source code for it ) I wrote a real basic form app in
Visual Studio, with two edit boxes, with data in each.
Now this basic app shows the text values immediately
on startup. So there must be something different that
the database app is not doing.
I then ran wine using 'wine --debugmsg +edit
programname' for both app's.
I see both logging 'Creating ANSI edit control, style
= xxxxx'
but the style reference is different between apps - I
am not sure if this the cause or not.
The problem app reports style = 54011104 and the basic
app shows style = 50010080.
Can somebody explain what this style reference means
and how do I force an app to use a certain style of
edit box ?
What other wine class debugmsg types should I use to
narrow down the source of this problem ?
Is there anyway I can check to see how the database
app is repainting text within the text edit components
?
Regards
Doug Herbert.
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
>>Well, apparently we don't use sched_yield, so the problem must
>>> lie somewhere else. Maybe Con can help us out here? Alexandre says he
>>> doesn't know what the issue is either and somebody needs to investigate. I
>>> guess we do need to concern ourselves over the details :)
>
>
> Interesting. Probably the most valuable information is that it seems to
> work fine if we artificially limit the threads to exactly the same
> timeslice _or_ we put them at such a low priority that they are forced
> to be guaranteed to round robin one task at a time. This is the way 2.4
> used to work which is why with the new 2.6 schedulers which do far more
> out-of-order rescheduling some applications have a problem; particularly
> under load. I suspect it's actually the latter issue. Locking between
> threads should prevent that being a problem, though. You already
> mentioned that you dont use sched_yield() and I couldn't even begin to
> look at the wine code myself so perhaps you know something more.
Hi Con,
One thought that occurred to me, and this is just a random theory, is
that maybe the issue is not with the Wine code but the Win32 code run on
top of it. Do you know how 2.6 scheduling compares with 2.4 and Windows
(NT) scheduling? Could it be that some apps are written to expect
Windows-style scheduling and fail to work if they don't get it?
In case you hadn't noticed, I'm afraid I only have first-year CS
knowledge of scheduling :/
thanks -mike
Hello,
Once again cross-posting because I would like to see if this is
something we can work together on. What is left to do for us to be able
to build and have a working implementation of stdole.tlb or any other
type libs? I ask because it seems Wines DCOM implementaton is almost
good enough for most apps except for this file and ReactOS is quickly
getting to the point that it can run most of the same stuff Wine can
without DCOM9x installed.
Thanks
Steven
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
The following change to dlls/commdlg/fontdlg.c
revision 1.70
date: 2004/08/14 00:42:35; author: julliard; state: Exp; lines: +2 -5
Jacek Caban <jack(a)itma.pwr.wroc.pl>
Fix a bug in passing parameters to CFn_WMInitDialog and CFn_WMCommand
in FormatCharDlgProcW.
causes the following warning with GCC 3.3.2 on FreeBSD 4.10:
fontdlg.c:1161: warning: passing arg 4 of `CFn_WMCommand' from incompatible pointer type
Would you mind fixing this?
Thanks,
Gerald
--
Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/
>> I'm just wondering if it is supposed to work as well as FreeBSD stable.
Right now, Wine doesn't work at all on FreeBSD -STABLE:
wine: failed to initialize: /swtest/wine/dlls/ntdll.dll.so: mmap of
entire address space failed: Cannot allocate memory
and before that I used to see deadlocks upon startup of non-trivial
applications (such as Forte Agent, both 16bit and 32bit flavors).
I believe there are also signficant threadings issues on -CURRENT, so
overall Wine is hardly, if at all, usable on any version of FreeBSD I
have access to, even though I'm still working to keep it at least
compilable on FreeBSD 4.9 and 5.2/5.3.
Gerald
--
Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/
I played a bit with smatch and Wine (after reading
http://people.redhat.com/mstefani/wine/smatch/), to try to get over what
I mentionned in my last email (regarding winapi_check and cross-calls in
parenthesis).
I attach the smatch script to generate the results I have. It's still
not perfect (the listview.c references are wrong, for example), but as
it's tied to gcc it can detect some calls which otherwise would not be
caught. For example, the calls to GetWindowLongA in header.c are in a
macro.
Not all of them are bugs: caution is needed when checking, although
reducing the number of false positive would likely be welcome (either by
modifying the script or patches).
Vincent
Hello,
By accident, I removed the emails of the thread I started, but I'll look
it up if necessary;
I found this old wine issue of some time ago.. I think the patch it has
there could be helpfull
http://winehq.org/?issue=229#About%20Converting%20W-%3EA%20Calls
However, I don't know how to make simple tests.. as I'd really need to
test wether the code I write works, and works properly :p
How do I write tests for that? I'm running linux (in practice, I never
boot into windows) so how should I do this (testing without windows
environment)? How are tests supposed to run?
I hope you can give some clues on that; I found there are many W->A
calls in dlls/winmm/winmm.c (according to the janitorial page) so I
might start there (hoping not all of them are so tricky ;) )
Thanks for suggestions on this,
Joris
Hiya, I've just set up a temporary Linux system to try to get back into
doing some wine development following a break and thought I'd start by
looking at some bugzilla bugs for now. I'm sure there used to be a page
which showed the lifespan of a bug but for the life of me I cant see it.
My understanding is I accept it and assign to myself, then fix it, then
what... Do I put the bug in fixed state and submit the patch or leave that
change to the raised?
Jason
On Thu, 29 Jul 2004 23:19:11 -0500, Alexandre Julliard wrote:
> Log message:
> James Hawkins <truiken(a)gmail.com>
> Under the Drives tab, remove the 'Windows Drive' section.
You probably want to increase the size of the drive mappings list so it
fills the tab, currently there is just a lot of empty space at the top of
the pane now you removed the old stuff.
Also we should kill the autodetect button. This is done by
wineprefixcreate these days, or should be.
Other things are:
- Drive editing seems broken. The list box only updates the second time I
hit edit. err:winecfg:applyDriveChanges unable to set volume label for
devicename of 'H:\', label of ''
- Browse in the "Add/Edit drive" dialog is a WRITEME
- Build system isn't right: I did a cvs update but the res files weren't
recreated properly. I had to do a make clean to get the gui updates.
- "Add Application" has poor usability: we always use a file browser
dialog box even though the most common use case is just "foo.exe", ie
the user knows the name and doesn't care about the location. Worse we
start in the c:\windows\desktop folder for some reason, meaning users
might accidentally select a .lnk file!
Ditto for Libraries tab.
- The Add/Remove application buttons are *way* too big!
- Obviously, once audio autodetection has been moved into the drivers we
need to kill the audio tab.
- Libraries tab just has generally poor usability, actually. The first
item in the radio group is "Builtin" meaning that's the one users are
most likely to select, it should be "builtin, native" followed by "native,
builtin"
- We ask the user to understand a magic * symbol to set the default - what
is up with that?
- There are no helpful default entries in the drop down box for setting a
DLL override, and when you add one the tree does not expand so to actually
*set* it you have to expand the tree then select the new override.
- We have way too many (eg, more than zero) tree controls in this app.
- Drive mappings list is really unclear, there's no separation between the
"Drive X:" label and the unix path its mapped to.
Basically I'd recommend reading the GNOME HIG:
http://developer.gnome.org/projects/gup/hig/
it's a very informative read. Obviously we have to use Win32 UI
conventions at least at first, but there's a lot of generically good
advice there. Well worth reading for anybody who is going to work on
winecfg.
thanks -mike
