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
>> 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/
Hallo,
I sent a patch to prevent wine from crashing last friday. It happend, when
DRIVER_FindFromHDrvr returned NULL. No I found out, that I had sent that
patch before last year. Eric answered
> this doesn't seem right to me: either the loading fails and we shouldn't
> get a valid handle, or it succeeds and we should be able to find it
> there's must be something wrong elsewhere
> could you please send a -debugmsg +driver,+module,+winmm to see what
> happens ?
and like before, I can't reproduce the error after reverting the patch:
> the error no longer exists. I guess some registry entry was corrupt and a
> successfull run corrected it later.
>
> However I see a lot of check after DRIVER_FindFromHDrvr() in other parts of
> the code...
If one dose "grep -3 DRIVER_FindFromHDrvr wine/dlls/winmm/*", every other
usage of DRIVER_FindFromHDrvr is like if
((lpDrv = DRIVER_FindFromHDrvr(hDrvr)) != NULL)
Why should expecting a NULL return be wrong? It happens, as the the crashes
show.
Bye
--
Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Hi people,
I think I discovered a wine bug.
In a delphi program, changing the visibility of a menuitem (TMenuItem)
causes the whole menu of that form to stop working, when the program is
run under Wine.
Behind the screens, the setVisible of a menu item calls MenuChanged.
This seems to put the menu in such a state that, in wine, all menu
components stop doing anything.
I've written a small application (455 kb EXE) to show what goes wrong.
Would anybody be interested to help me in solving this bug? Would a
message trace from Winsight (for example) be of any help?
Greetings,
Robert
I'm thinking how to implement CreateRemoteThread and besides fix memory management functions.
The complete (afaik) list includes:
RtlCreateUserThread
NtAllocateVirtualMemory
NtFreeVirtualMemory
NtProtectVirtualMemory
NtQueryVirtualMemory
NtLockVirtualMemory (do nothing?)
NtUnlockVirtualMemory (do nothing?)
NtFlushVirtualMemory
NtMapViewOfSection
NtUnmapViewOfSection
Suggested implementation.
Let's add two groups of handlers to the wineserver, something like remote_operation_xxxx
and remote_operation_xxxx_complete.
remote_operation should do the following:
1) suspend_for_ptrace();
2) inject a piece of code into required process and start its execution;
3) resume_after_ptrace();
4) place calling thread into suspended state (or into some wait state?)
remote_operation_complete should prepare reply and resume thread suspended by remote_operation.
Injected code should call required function and then remote_operation_complete
in context of required process.
The question is: how to correctly get address of function?
imho possible solutions are:
1) assume ntdll loaded at the same address for all processes -- unreliable;
2) get dll base address from per-process dll list and parse ELF by hand -- too complicated (?);
3) pass relative offsets and add them later to the ntdll's base address -- unreliable
a bit: ntdll may be replaced, although, it is unlikely;
4) extend the struct process (server/process.h) and the request init_process with
pointers to required functions -- most reliable and simple but looks ugly.
What do you think?
I'm interested in possibly working on USB support for Wine. I'm not
particularly familiar with USB programming, but I'm fluent in C and C++.
Where do I start?
Robert Reif wrote:
> Notify when position format not supported.
> Test that position is 0 at start.
Good patch. I was worried that tracing all waveGetPosition() failures
would clober the output but after that's what one wants when tracing is
enabled. Plus it uncovers interesting results:
wave.c:584:found 1 WaveOut devices
wave.c:472: 0: "SigmaTel Audio"
(\\?\pci#ven_8086&dev_24c5&subsys_01641028&rev_01#3&61aaa01&0&fd#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\wave)
5.10 (1:100): channels=65535 formats=bffff support=002c(WAVECAPS_VOLUME
WAVECAPS_LRVOLUME WAVECAPS_SAMPLEACCURATE)
wave.c:482:Playing a 5 seconds reference tone.
wave.c:483:All subsequent tones should be identical to this one.
wave.c:484:Listen for stutter, changes in pitch, volume, etc.
wave.c:369:Playing 5 second 440Hz tone at 22050x 8x1
wave.c:268:TIME_MS not supported, returned TIME_SAMPLES
wave.c:290:TIME_SMPTE not supported, returned TIME_SAMPLES
wave.c:268:TIME_MS not supported, returned TIME_SAMPLES
wave.c:290:TIME_SMPTE not supported, returned TIME_SAMPLES
...
I get the same results on Windows 95, 98 and NT4. How is it that this
works on your machine?
Anyway, assuming that we need to round up I propose to modify the
implementation as in the attached patch. The advantage is that it does
not rely on ceil(). In fact it doesn't even use floating point
arithmetic so we cannot get any rounding error.
If this patch is ok by you, then I can apply it to all the drivers.
I also noticed that we have similar code for the input devices. Does
this one also round up? Or does it round down? (I could very well see MS
make that one round down)
--
Francois Gouget
fgouget(a)codeweavers.com
Index: dlls/winmm/wineoss/audio.c
===================================================================
RCS file: /var/cvs/wine/dlls/winmm/wineoss/audio.c,v
retrieving revision 1.135
diff -u -r1.135 audio.c
--- dlls/winmm/wineoss/audio.c 19 Jul 2004 20:08:06 -0000 1.135
+++ dlls/winmm/wineoss/audio.c 20 Jul 2004 08:58:43 -0000
@@ -2077,7 +2077,6 @@
*/
static DWORD wodGetPosition(WORD wDevID, LPMMTIME lpTime, DWORD uSize)
{
- double time;
DWORD val;
WINE_WAVEOUT* wwo;
@@ -2116,15 +2115,21 @@
TRACE("TIME_SAMPLES=%lu\n", lpTime->u.sample);
break;
case TIME_SMPTE:
- time = (double)val / (double)wwo->format.wf.nAvgBytesPerSec;
- lpTime->u.smpte.hour = time / (60 * 60);
- time -= lpTime->u.smpte.hour * (60 * 60);
- lpTime->u.smpte.min = time / 60;
- time -= lpTime->u.smpte.min * 60;
- lpTime->u.smpte.sec = time;
- time -= lpTime->u.smpte.sec;
- lpTime->u.smpte.frame = round(time * 30);
- lpTime->u.smpte.fps = 30;
+ val = val / (wwo->format.wBitsPerSample / 8) / wwo->format.wf.nChannels;
+ lpTime->u.smpte.sec = val / wwo->format.wf.nSamplesPerSec;
+ val -= lpTime->u.smpte.sec * wwo->format.wf.nSamplesPerSec;
+ lpTime->u.smpte.min = lpTime->u.smpte.sec / 60;
+ lpTime->u.smpte.sec -= 60 * lpTime->u.smpte.min;
+ lpTime->u.smpte.hour = lpTime->u.smpte.min / 60;
+ lpTime->u.smpte.min -= 60 * lpTime->u.smpte.hour;
+ lpTime->u.smpte.fps = 30;
+ lpTime->u.smpte.frame = val * lpTime->u.smpte.fps / wwo->format.wf.nSamplesPerSec;
+ val -= lpTime->u.smpte.frame * wwo->format.wf.nSamplesPerSec / lpTime->u.smpte.fps;
+ if (val != 0)
+ {
+ /* Round up */
+ lpTime->u.smpte.frame++;
+ }
TRACE("TIME_SMPTE=%02u:%02u:%02u:%02u\n",
lpTime->u.smpte.hour, lpTime->u.smpte.min,
lpTime->u.smpte.sec, lpTime->u.smpte.frame);
Is it known that console message printed to output in wine
internal encoding (OEM?), not in locale encoding. Is it bug or
just needed coding right behavior?
For example, I have koi8-r as locale encoding, cp866 as OEM CP
and cp1251 as ANSI CP.
--
Lav
Vitaly Lipatov
Saint-Petersburg
GNU! ALT Linux Team! LaTeX! LyX!
Hi,
If I start a simple OLE hello world app (shouldn't really matter what app
it is though) and run "b CoRegisterClassObject" winedbg crashes:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1075380896 (LWP 4932)]
0x408a2562 in symt_find_nearest (module=0x403e4248, addr=1081494000) at symbol.c:623
623 symt_get_info(&module->addr_sorttab[0]->symt, TI_GET_ADDRESS, &ref_addr);
(gdb) bt
#0 0x408a2562 in symt_find_nearest (module=0x403e4248, addr=1081494000) at symbol.c:623
#1 0x4089693b in elf_new_wine_thunks (module=0x403e4248, ht_symtab=0x4087dc70, num_areas=8, thunks=0x4087dc80) at elf_module.c:368
#2 0x40897071 in elf_load_debug_info (module=0x403e4248) at elf_module.c:598
#3 0x4089894d in module_get_debug (pcs=0x40330d80, module=0x403f44d0) at module.c:215
#4 0x408a2b3d in SymEnumSymbols (hProcess=0x30, BaseOfDll=0, Mask=0x4087de24 "*!CoRegisterClassObject",
EnumSymbolsCallback=0x4076585c <sgv_cb>, UserContext=0x4087e164) at symbol.c:807
#5 0x40765cfc in symbol_get_lvalue (name=0x415b0038 "CoRegisterClassObject", lineno=-1, rtn=0x4087eb4c, bp_disp=1) at symbol.c:231
#6 0x4075a58a in break_add_break_from_id (name=0x415b0038 "CoRegisterClassObject", lineno=-1) at break.c:244
#7 0x4076b25f in yyparse () at ./dbg.y:216
#8 0x4076c98b in parser (filename=0x0) at ./dbg.y:562
#9 0x40769f73 in dbg_main_loop () at winedbg.c:991
#10 0x4076a2c1 in main (argc=2, argv=0xbffff608) at winedbg.c:1229
#11 0x407592f1 in __wine_exe_main () from /opt/wine/lib/wine/winedbg.exe.so
#12 0x4049f953 in start_process (arg=0x0) at process.c:995
#13 0x400307a9 in wine_switch_to_stack () from /opt/wine/lib/libwine.so.1
(gdb) print module
$1 = (struct module *) 0x403e4248
(gdb) print module->addr_sorttab[0]
$2 = (struct symt_ht *) 0x0
Eric, any ideas? I don't understand what this code is doing.
thanks -mike
