e command is writing
> high-resolution (i.e., millisecond) time stamps, and it is only
> reading that high-resolution time stamp that seems to be an
> issue for MSYS on Wine.
Indeed.
Since Cygwin has a different view, the situation should improve with MSYS 2.
Cheers,
Peter
ead, that setup.exe itself does not depend on cygwin, and
> use no part of it.
Running the official installer invokes child processes that do indeed
require a functioning Cygwin DLL. I.e. post-install scripts (and pre-
remove scripts, but we're talking about the initial install so that's
out of scope).
The registry entries you speak about are a thing of the past, if you
are referring to mount points.
Cheers,
Peter
pts, which is certainly more work and more error-prone than
duplicating the download and unpacking of a few tarballs.
Cheers,
Peter
e32, even with
this hack, because the 32-bit packages for 64-bit Gentoo are supplied as
pre-compiled binaries and osmesa is disabled in those.
Can I build wine64 --with-osmesa and WoW wine32 --without-mesa and still
expect things to work?
Best regards,
Peter Urbanec
diff --git a/co
I just turned on --with-osmesa and configure fails for me:
checking for -lOSMesa... not found
configure: error: libOSMesa development files not found (or too old),
OpenGL rendering in bitmaps won't be supported.
This is an error since --with-osmesa was requested
config.log output would sugge
för att låta dig ändra "
> "inställningar i de flikarna också, antingen systembreda eller per program."
>
I believe 'systemövergripande' would be better than 'systembreda'.
>
> #: winecfg.rc:83
> -#, fuzzy
> msgid "Audio test failed!"
> -msgstr "Återställning av hårddisk misslyckades\n"
> +msgstr ""
Maybe "Ljudtest misslyckades!" ?
>
> #: winecfg.rc:85
> -#, fuzzy
> msgid "(System default)"
> -msgstr "Systemsökväg"
> +msgstr ""
Maybe "(Systemstandard)" ?
> #: winefile.rc:197
> msgctxt "accelerator Fullscreen"
> @@ -13528,9 +13355,8 @@ msgid "Error while selecting new font."
> msgstr "Ett fel uppstod när ett nytt teckensnitt valdes."
>
> #: winefile.rc:95
> -#, fuzzy
> msgid "Wine File Manager"
> -msgstr "Winefile"
> +msgstr "Wine Filhanteraren"
"Wine Filhanterare", unless we want definite form "The Wine File Manager".
> #: wordpad.rc:188
> -#, fuzzy
> msgid "OLE storage documents are not supported."
> -msgstr "Utökade attribut ej stödda\n"
> +msgstr ""
Maybe "OLE lagringsdokument stöds ej." ?
//Jan-Peter
joerg-cyril.hoe...@t-systems.com skrev 2012-01-31 15:23:
> Peter Rosin wrote:
>>> Of the same vein, one liners like
>>> EnterCS
>>> This-> playing = StateStopped;
>>> LeaveCS
>>> are suspicious too. What does that guarantee?
>> Per
) and three()?
EnterCS
if (This-> playing == StateRunning) {
one();
}
two();
if (This-> playing == StateStopped) {
three();
}
LeaveCS
I don't know whether, or not, that has any bearing what-so-ever on
the patch under discussion...
Cheers,
Peter
you help,
Kind Regards,
Peter Wilson
wine-devel has been seeing more and more robot generated messages. Would
it make sense to create wine-bots list for buildbot, testbot and
friends? Automated messages could go to author, wine-bots with Reply-To:
and Followup-To: pointing at wine-devel
That way wine-devel could be returned to hu
overwrite too much data.
Nope, you are mistaken and the OP is correct.
%e float
%le double
%Le long double
Cheers,
Peter
If so, is there any chance that someone
may be able to provide x86_64 implementation in the near future? It's
way over my head :-(
Best regards,
Peter Urbanec
On 01/03/11 17:13, John Klehm wrote:
Nice find on this code path being able to run without loading xinput.
It was as a result of a user sending me some crash logs. I never managed
to reproduce this issue. I don't even have access to a tablet to test.
My patch was pretty much a result of "NUL
orkingSetSize 3689ac000
PeakPagefileUsage 3f2baf000, PagefileUsage3eccd
Global:
TotalPhys 3eb4f2000, AvailPhys 0c4d8000
TotalPageFile 66b984000, AvailPageFile1733eb000
TotalVirtual7ffd, AvailVirtual 7ffc1330
Cheers,
Peter Urbanec
On 26/02/11 04:12, Marvin wrote:
http://testbot.winehq.org/JobDetails.pl?Key=9486
=== W7PROX64 (64 bit status) ===
status.c:412: Test failed: Expected 1, got 0
Please ignore all 3 patches in the set. I will investigate Win behaviour
a little closer and resubmit the patches once I learn more.
n caused the
page fault in memcpy(). With the (LONG) cast in place, I see sbits
changing from 0x240004 to 0x24, as expected.
Using gcc (Gentoo 4.5.2 p1.0, pie-0.4.5) 4.5.2 with -O0
The addition of the cast fixes the issue and allows the winetest to succeed.
Cheers,
Peter Urbanec
As of a few days ago, I'm seeing the following errors when building
wine64 with gcc (Gentoo 4.5.2 p1.0, pie-0.4.5) 4.5.2
dlls/msvcr90/tests/msvcr90.c:137:14: warning: 'do_call_func1' defined
but not used
dlls/msvcr90/tests/msvcr90.c:147:14: warning: 'do_call_func2' defined
but not used
dlls/m
On 08/02/11 16:02, Marvin wrote:
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=9028
Your paranoid android.
=== WNT4WSSP6 (32 bit clipping) ===
clipping.c:438: Test failed: expected 0,0-0,0, got 0,0-800,600
It seems that GetSystemMetrics(SM_CXVIRTUALSCREEN) is suppo
Den 2011-02-04 20:36 skrev Peter Rosin:
> Den 2011-02-04 17:41 skrev André Hentschel:
>> % and / both lead to external dependencies here...
>> maybe the euclidean algorithm helps, because -Os would need ugly changes to
>> configure i guess.
>>
>
> Finding gcd
t;%" btw,
>>
>> return a%b;
>>
>> but this might generate external functions too... hmm, try -Os as option?
>>
>> Ciao, Marcus
>
> % and / both lead to external dependencies here...
> maybe the euclidean algorithm helps, because -Os wo
7;s no alpha channel, which is what we are checking here.
Ouch! If that is really Windows behaviour, then it is really broken but
bug-to-bug compatible :)
Cheers,
Peter
Peter Schlaile
Hi Alexandre,
On Mon, 31 Jan 2011, Alexandre Julliard wrote:
Peter Schlaile writes:
Fix: X11DRV_SetDIBits() shouldn't silently change Bitmap protection, so
we now restore the protection bits, that were present before instead of
always changing to READONLY.
No, it needs to be read
Hi Vitaliy,
On Sun, 30 Jan 2011, Vitaliy Margolen wrote:
On 01/30/2011 04:16 AM, Peter Schlaile wrote:
Hi,
find fix for a crash in create_alpha_bitmap() attached.
If it's easy to reproduce please create a test that demonstrates the problem.
hmm, don't know, the application that
RPMs or other distro specific packages, hassle your
distribution maintainers. (Or switch to Gentoo ;-)
Both AMD and Intel also have OpenCL implementations/SDKs available.
Their distro support varies.
Best regards,
Peter Urbanec
On 01/12/10 22:47, Alexandre Julliard wrote:
Peter Urbanec writes:
Second, I am anticipating that when wine OpenCL 1.1 support
is added, we'll need to determine whether the host is using OpenCL 1.0
or 1.1, at runtime.
How is that going to work?
OpenCL 1.1 remove
On 01/12/10 12:33, Roderick Colenbrander wrote:
OpenCL is a little different of course, but I fear that not all OpenCL
implementations will like wrapping. What OpenCL applications have you
tried so far? The Nvidia GPU Computing SDK (or whatever it was called)
has a ton of samples for both Cuda an
On 30/11/10 21:15, Alexandre Julliard wrote:
Why are you loading everything dynamically instead of simply linking
to it?
Couple of reasons. First, a machine may or may not have an OpenCL
implementation installed and it may or may not have the required
hardware. Second, I am anticipating tha
prefer the untested #ifdef
__APPLE__ variant, I'm happy to resubmit the patch.
Cheers,
Peter Urbanec
Den 2010-11-29 08:36 skrev Peter Rosin:
> Den 2010-11-29 01:03 skrev James Eder:
>> On 11/26/10 12:15 AM, Damjan Jovanovic wrote:
>>> On Fri, Nov 26, 2010 at 6:56 AM, Vitaliy Margolen
>>> wrote:
>>>> On 11/24/2010 07:19 PM, James McKenzie wrote:
>>&g
nd the line ending. The proposed function a few messages back
would in that case read two lines into the buffer, and they would be
separated by a CR.
For this reason, I consider fgets completely unusable (on Windows) for
anything where the maximum line length isn't known in advance.
But maybe wine does not have this problem? However, my XP SP3 sure does.
Cheers,
Peter
l forward it in private.
Cheers,
Peter Urbanec
ger.
I'm happy to provide test source code, 64-bit and 32-bit binaries and
matching PDB files, if anyone is interested in looking at the issue.
Cheers,
Peter Urbanec
mixdev[mixnum].chans += !!mastelem + !!headelem + !!pcmelem +
> (micelem && !mastelem && !captelem);
> ducks quickly ... :-)
Clearly not, since it is harder to debug code than to write it, and you
failed to write it correctly in the first place (assuming the patch was
indeed correct).
Good thing you ducked... :-)
Cheers,
Peter
I see calls to the following two functions just prior to a crash when
testing wine64. Any idea what these are?
wine: Call from 0x7b8497d9 to unimplemented function
msvcp80.dll.??0?$comp...@n@std@@q...@aebn0@Z, aborting
wine: Call from 0x7f7b04cf40d9 to unimplemented function
MSVCR80.dll.__C_s
I have some x64 binaries and associated PDBs that have been generated
using Intel C++ Compiler 11.1. These PDBs cause issues such as this:
1 0x781cc1ba in msvcr80 (+0x9c1b9) (0x7ff047a4c840)
fixme:dbghelp_msc:codeview_fetch_type Cannot locate type 670
err:dbghelp_msc:pe_load_debug
On 18/08/10 01:51, Marcus Meissner wrote:
On Wed, Aug 18, 2010 at 01:00:35AM +1000, Peter Urbanec wrote:
I'm seeing crashes in FindNextFileW/FindNextFileA due to what
looks like a 64 bit HANDLE value being truncated to 32 bits.
Check if your code uses "int" in its FindNextFi
ModeFlat' failed.
wine: Assertion failed at address 0x7fec2fa657c5 (thread 0009), starting
debugger...
Unhandled exception: assertion failed in 64-bit code (0x7fec2fa657c5).
Any ideas about why I can not use winedbg to run Win32 x64 code?
Thanks,
Peter Urbanec
On 20/07/10 04:54, Ian Macfarlane wrote:
Following the question as to how to implement D3DXCreateTeapot, might
I suggest making it in the form of a wine glass?
Given that is unlikely to negatively affect anything (indeed the
entire method does border on the ridiculous) I think it would make a
Since kthreads has now been removed, references to it in the
developer's guide should presumably be removed. What about NPTL?
Should discussion comparing it to kthreads be removed?
Peter
On 12/07/10 20:44, Paul Chitescu wrote:
On Monday 12 July 2010 12:49:02 pm Peter Urbanec wrote:
Wine itself provides msvcr90.dll.so, which as far as I can tell doesn't
play the manifest games or provide any particular version number.
Should I be using msvcr90.dll from VC redist?
Should
I'm trying to get my head around the mess generated by SxS, isolated
apps, embedded manifests, local deployment and all the other "solutions"
to DLL hell. It's hard enough to make it work on Windows, but making it
work well under wine is another challenge.
In a nutshell, I'd like to ship a cu
ncing information are not
going to be the sort to enter bogus information. Wikipedia has a high
level of accuracy despite its openness.
Peter
> What's wrong with strncmp?
strncmp(arg, str, sizeof(str)-1) looks ugly.
Peter
ocumenting,
implemented fairly efficiently in a performance wise undemanding
program.
Peter
> My primary concern here is
> participation
Count me in! I think it would be a great way to learn the wine/windows
internals.
Peter
> Wine can load and parse resources just from
> winelib (dll.so/exe.so) binaries.
I assume that dll.so/exe.so are for all practical purposes identical
to .dll/.exe except they can't be run on windows.
Peter
UrlA/W by name will work
with both XP and post-vista programs, not exporting it by name will
break post-vista programs. If a function was removed after a certain
version, it wouldn't be removed in wine.
Peter
reloader' from a normal build. As noted elsewhere -fprofile-dir
won't work (I intend to fix this soon).
Peter
uot;, "-fprofile-generate" or "-fprofile-use" to winegcc
without arguments. It started as a hack to enable gcov and evolved
into a hack to enable PGO and gcov.
Peter
d into it, it seems that these files are usually deleted
by 'make depend' and are only temp files (I probably stopped "make
depend" with ^C to generate them).
The pattern is broken anyway since it also catches "configure", etc.
Peter
Does this mean that "make depend" should be removed from README and
./tools/wineinstall? It generates /conf* files.
Peter
On 18 June 2010 01:50, Scott Ritchie wrote:
> Hey Peter,
>
> Was just hoping you'd make the (I believe trivial) change to your gcov
> patch that Alexandre wanted and submit it by tomorrow so it creeps into
> the next RC. I want to start messing around with profiled package
&
>LDFLAGS are already passed to winegcc where appropriate.
Oops, hadn't noticed they got in though $(ALL_LIBS), you can omit that
part of the patch then.
Why do we silently drop unrecognized args in "winegcc" anyway?
Peter
On 16 June 2010 02:37, Dan Kegel wrote:
> But does PGO improve performance measurably?
>
Probably, to test it I need a program that runs wine like a typical
program, that I can run autonomously. Anyone have any ideas?
Peter
work for
some reason)
To use PGO
Run "make EXTRACFLAGS=-fprofile-generate LDFLAGS=-fprofile-generate"
Run sample program (test suite is inappropriate because it doesn't
represent normal usage).
Run "make clean"
Run "make EXTRACFLAGS=-fprofile-use LDFLAGS=-fprofile-use"
Peter
s is like
"Flag FOO unsupported", which is not the same as a stub. Maybe we
could have STUB macro to be called in stub functions.
Peter
I'll resend the patch and
make sure it helps with PGA.
Peter
On 14/06/10 18:12, Edward Savage wrote:
I'm looking to try and fill out a WWN for this friday
I really think it would be very beneficial to go into some detail on the
64-bit support. In particular, it would be a good idea to outline the
expected user experience when running a 64-bit app.
On 14 June 2010 18:40, Damjan Jovanovic wrote:
>
> Since around 2-3 months ago, you don't need to run "make depend" at all :-).
>
> Damjan
>
Then why is it still there?
Peter
How often do I need to run "make depend"?
Peter
On 12 June 2010 00:23, Aneurin Price wrote:
> Is it a legal requirement that everyone working on WINE must be a
> complete arsehole, or just a project requirement?
>
> Nye
Which side are you on?
Peter
How do I get the test suite to report it success rate (as a whole) in
a "%d tests executed (%d marked as todo, %d %s), %d skipped.\n" style.
Peter
Some tests crash for me (eg.
http://bugs.winehq.org/show_bug.cgi?id=22903 segfaults). This means I
can't run the entire test suite with "make test", what should I do?
Peter
he first place)
There is nothing that bugs me more than not being told why I'm wrong.
Peter
I did a git bisect to test the "bt all" issue and narrowed down the issue:
d29c6ead9280a174fa07ec7d5cd07293c3f7832d is the first bad commit
commit d29c6ead9280a174fa07ec7d5cd07293c3f7832d
Author: Eric Pouech
Date: Tue Mar 30 21:37:01 2010 +0200
winedbg: Store the CONTEXT in each stack fra
On 09/04/10 19:10, Peter Urbanec wrote:
On 07/04/10 06:39, Dan Kegel wrote:
winedbg's bt all seems broken since sometime between 1.1.40 and now.
Has anybody else seen this?
If I start a program under debugger control with "./wine winedbg
~/test/my.exe" then I see errors suc
On 07/04/10 06:39, Dan Kegel wrote:
winedbg's bt all seems broken since sometime between 1.1.40 and now.
Has anybody else seen this?
If I start a program under debugger control with "./wine winedbg
~/test/my.exe" then I see errors such as "Can't get context for thread
0021 in current proc
you do that anyway with anything
sufficiently non-trivial you get to keep the pieces, so the
suggestion to use -L/usr/lib/w32api -lmsvcrt with the native
Cygwin gcc is not good even if it appears to work. (hmmm, was
that even the suggestion?)
Cheers,
Peter
--
They are in the crowd with the answer before the question.
> Why do you dislike Jeopardy?
...
Cheers,
Peter
--
They are in the crowd with the answer before the question.
> Why do you dislike Jeopardy?
Has anyone investigated wine support for OpenCL apps?
What is required to support Win32 OpenCL apps, assuming the host machine
has modern hardware, like an NVidia GT240?
Forgot wine-devel,
>>I'm lost here as TrackPopupMenu() is not called in a loop. It's only
called once. So which API function are you referring to?
I was referring to the "loop" we got into on NT4 where the proc handler
would be re-entered again and again. My idea was that if this happened on 9x
a
>> But maybe not with a window that's in the process (or already) of being
destroyed (in the callback).
OK, but in the the first run of the "loop" we are not in the process of
destroying the window, as DestroyWindow has not been called yet. Am i
missing something? Are there other things that cause
> It took a while but I found the culprit. The crash is most likely because
> the window is (about to be) destroyed.
>
> The only thing left to do is to fix the 211 test failures on NT4.
>
> I fixed a typo while at it and used a define instead of a magic value.
>
>
>
Are you sure this is the right
Hey Paul,
Thanks for cleaning up the crashing 9x test-case so fast.
> This patch has introduced test failures on NT4 and below (tested locally):
>
> http://test.winehq.org/data/tests/user32:win.html
Sorry for that.
> The callback is entered several times on NT4 (only once on XP) so it
> seems.
On Mon, 2010-01-11 at 14:00 -0600, Alexandre Julliard wrote:
> Is there actually an app that depends on this?
http://bugs.winehq.org/show_bug.cgi?id=9369
This bug requires the function to fail, but you are probably right that
no-one checks the error code. I will change the patch/test to be less
p
> Simply use wine_server_call instead of wine_server_call_err.
That is my point. That will not work. The existing the error codes
*should* be translated, but this new one should not. So if i use
wine_server_call i would have to filter which ones to translate
manually.
It would also give me the p
does this.
Thanks,
/pedro
On Fri, 2010-01-08 at 10:06 +0100, Alexandre Julliard wrote:
> Peter Dons Tychsen writes:
>
> > @@ -85,6 +85,17 @@ BOOL set_capture_window( HWND hwnd, UINT gui_flags, HWND
> > *prev_ret )
> > HWND previous = 0;
> > UINT flags = 0;
&
On Sat, 2009-12-26 at 20:53 +0100, Jacek Caban wrote:
> We can't really change the language as Windows doesn't provide English
> resources for most binaries and executables on on non-English
> installations.
Why not just have the tests file check the locale, and then do skip()
for the language dep
On Fri, 2009-12-25 at 19:55 -0800, Dan Kegel wrote:
> So, where should the tests live? I had been thinking
> programs/cmd/tests,
> but maybe something like programs/tests would be better
> given that it can test more than just cmd.
I think it would make most sense to follow the current strategy o
On Tue, 2009-12-22 at 15:36 -0600, Austin English wrote:
> Sure. FWIW, I'm working on some AutoHotKey/Appinstall tests for cmd,
> but it's a bit difficult, since the only way to capture the stdout is
> to pipe it to a file first.
Hey, i think a test suite for cmd is an excellent idea, and is surel
em here? Maybe more Brains come
up with more
approaches. I hesitate to do so: To much cooks corrupt the porridge. :)
Regards
Peter
> On Mon, Dec 7, 2009 at 8:41 AM, Vitaliy Margolen
> wrote:
>> Peter Kovacs wrote:
>>> Now Vitaliy Margolen actively stopped the
>&g
hanks Listening, hope you got the Problem I want to address.
I am not on the list since I develop nothing for wine. I would it appreciate it
a lot, if I could stay with the discussion by keeping my email address in CC
Regards
Peter
.
I don't really see the point of letting someone else update AUTHORS
for me though, but now Alexandre can pick whichever version he likes
best...
Cheers,
Peter
--
They are in the crowd with the answer before the question.
> Why do you dislike Jeopardy?
ormal wine build process.
Jacek, any ideas on what could/should be done to align the Gecko build
process with the wine build process? Is it possible to have minimal
Win32 stubs and keep most of the Gecko engine native?
Cheers,
Peter Urbanec
Eric Pouech wrote:
Peter Urbanec a écrit :
It can't be as simple as updating the value of dbg_curr_thread with
the result of dbg_get_thread(dbg_curr_process, tid) and then calling
GetThreadContext(dbg_curr_thread->handle, &dbg_context), can it?
the changes will need to be larg
Dan Kegel wrote:
start winedbg without any app
say 'bt all' in winedbg
Voila, you now have backtraces for every process, including the hung one.
It's your job to get that into a text file and remove the uninteresting ones...
I've also been trying to debug a multithreaded app. There are at
nisation mechanisms - any pointers where to look for
explanations?
Best regards,
Peter Urbanec
On Thu, 2009-10-15 at 19:19 -0500, Ken Thomases wrote:
> +static int once;
> +
> +if (!once++) FIXME("independent left/right volume not implemented
> (%f, %f)\n", left, right);
I know it is a detail, but is it not a bit misleading having a variable
called "once" when it will trigger the co
> Yes I understand your comments, but they show that you don't
> understand
> the code.
Of course i dont understand the code as well as you, as i only have used
a little amount of time studying it.
I was only hoping that my comments would spark a response which would
allow me continue with th
> What you should do first is spend a lot more time studying the code,
> before deciding that it has "major problems" and needs major
> changes. It's a very sensitive area where the smallest change has big
> consequences, and you have to be sure to know what you are doing.
I already spent time on t
> So... i have investigated other ways of fixing this. Would you accept a
> patch that uses _NET_WM_MOVERESIZ to move the window? That might also
> fix the issue. That message requests the WM to move the window at not X.
I have now tested with _NET_WM_MOVERESIZ & _NET_MOVERESIZE_WINDOW
No cigar. T
On Tue, 2009-10-06 at 14:37 +0200, Peter Dons Tychsen wrote:
> Hello,
>
> > You can do it at window creation time, but you can't
> > change the window back and forth just because you want some move request
> > to not be intercepted.
> >
> Eh? Did you rea
Hello,
> You can do it at window creation time, but you can't
> change the window back and forth just because you want some move request
> to not be intercepted.
>
Eh? Did you read the xlib manual i linked to? This is *exactly* what
they recommend for this type of scenario:
http://tronche.com/gu
I am posting your response, as you are not on CC in the bug.
>>You can't do that sort of thing. If you really don't want the window
manager to
>>control the windows there's an option for it, but you can't have it both ways.
I am not sure i agree. Everywhere i looked they referred to "override_red
On Fri, 2009-10-02 at 12:56 +0200, Michael Stefaniuc wrote:
> If even Windows 7 behaves that way I figure
> we'll have to provide that "feature" too. Else the application is
> buggy
> and won't work on all Windows versions either.
Even if it did not work in win-7, then it could still be worth fixi
On Thu, 2009-10-01 at 12:33 +0200, Alexandre Julliard wrote:
> Peter Dons Tychsen writes:
>
> > Just out of interest: You changed this to a write. Fine.
> > But why the volatile? Can GCC assume predetermined results when writing
> > to NULL? I don't see any reason t
Thanks V.
However, it would seem that AJ already has commited another fix in ntdlls
serial module (which fixes the same bug), so i guess my fix and tests are
not valid any more.
Thanks,
/pedro
- Original meddelelse -
> Fra: Vitaliy Margolen
> Til: Peter Dons Tychsen
> Cc: w
OK. The "bad handle" is tested by the "deadbeef" handle.
Where is the best place to get a really good "wrong class" handle?
Thanks,
/pedro
- Original meddelelse -
> Fra: Alexandre Julliard
> Til: Peter Dons Tychsen
> Cc: wine-devel@winehq.org
originated from GetStdHandle().
So i think using this API for testing is relevant, as the point of the
test is to verify that handles of the completely wrong class are
rejected, and not just "bad handles".
Thanks,
/pedro
- Original meddelelse -
> Fra: Alexandre Julliard
ity mount is surely just for fun. Anything MSYS
or Cygwin inside Wine is for fun. The identity mount technique
clearly does not work with Wine.
Cheers,
Peter
(*) Google: mingw "identity mount"
1 - 100 of 473 matches
Mail list logo