Can't install - Windows 8.1 Pro
---
Key: CORE-4517
URL: http://tracker.firebirdsql.org/browse/CORE-4517
Project: Firebird Core
Issue Type: Bug
Components: Installation
Affects Versions: 2.5.3
On 08/12/14 01:41, Dimitry Sibiryakov wrote:
> 11.08.2014 21:43, Adriano dos Santos Fernandes wrote:
>> You told before (and now) as y-valve is part of each provider. That's
>> not true.
> Not true even that I ever told that. Read carefully and you'll see that I
> name
> completely separate pa
On 08/11/14 22:29, Tom Coleman wrote:
>
> I interface a proprietary language with Firebird, Oracle, and Sybase/MS-SQL.
>
> There is never any case where I would want to see std:exception.
>
> Could it be time to start thinking about burying this idea that is looking
> more and more like a sacred
On 08/11/14 23:57, Tom Coleman wrote:
>
> On Aug 11, 2014, at 3:36 PM, Jim Starkey wrote:
>
>> You may be more interested in why something failed than just that it failed.
>>
>> An error mechanism should play nicely with the status vector to expose as
>> much -- or as little as the user needs. So
11.08.2014 21:43, Adriano dos Santos Fernandes wrote:
> You told before (and now) as y-valve is part of each provider. That's
> not true.
Not true even that I ever told that. Read carefully and you'll see that I
name
completely separate parts: outer world, Y-valve, providers, plugins. What I
On 11/08/2014 16:57, Tom Coleman wrote:
>
> On Aug 11, 2014, at 3:36 PM, Jim Starkey wrote:
>
>> You may be more interested in why something failed than just that it failed.
>>
>> An error mechanism should play nicely with the status vector to expose as
>> much -- or as little as the user needs.
On Aug 11, 2014, at 3:36 PM, Jim Starkey wrote:
> You may be more interested in why something failed than just that it failed.
>
> An error mechanism should play nicely with the status vector to expose as
> much -- or as little as the user needs. Sometimes an error code is enough,
> sometime
You may be more interested in why something failed than just that it failed.
An error mechanism should play nicely with the status vector to expose as much
-- or as little as the user needs. Sometimes an error code is enough,
sometimes a full formatted compound message is required.
But a secon
On 11/08/2014 16:37, Dimitry Sibiryakov wrote:
> 11.08.2014 21:28, Adriano dos Santos Fernandes wrote:
>> No. Providers and plugins should work when compiled by different
>> compilers and being in different libraries!
>That's why border guards must stay between engine and plugins. As well as
>
11.08.2014 21:28, Adriano dos Santos Fernandes wrote:
> No. Providers and plugins should work when compiled by different
> compilers and being in different libraries!
That's why border guards must stay between engine and plugins. As well as
between
Y-valve and outer world. Guards between Y-va
On 11/08/2014 16:19, Dimitry Sibiryakov wrote:
> 11.08.2014 21:13, Adriano dos Santos Fernandes wrote:
>> An integrated approach (who throws from IStatus, catchs and set IStatus)
>> is very welcome.
>I would suggest a very simple approach: push IStatus out of engine, just
> throw
> exceptions
11.08.2014 21:13, Adriano dos Santos Fernandes wrote:
> An integrated approach (who throws from IStatus, catchs and set IStatus)
> is very welcome.
I would suggest a very simple approach: push IStatus out of engine, just
throw
exceptions there. Leave catching and converting exceptions into IS
On Aug 11, 2014, at 2:40 PM, Adriano dos Santos Fernandes wrote:
> On 11/08/2014 15:29, Tom Coleman wrote:
>>
>> I interface a proprietary language with Firebird, Oracle, and Sybase/MS-SQL.
>>
>> There is never any case where I would want to see std:exception.
>>
>> Could it be time to start
On 11/08/2014 16:03, Dmitry Yemanov wrote:
>
> We either forget about exceptions completely, or throw some partially
> abstract class (thus forcing users to implement the exception before
> being able to compile), or maybe go for the policies you described.
>
> That said, I'd rather resolve the o
11.08.2014 22:08, Adriano dos Santos Fernandes wrote:
> But an (client) application wants to generate exception when accessing
> the API, and we do not know in advance what's the good classes for each
> project.
And we'll never know. This is not our business, IMO.
> Some may use like Firebird, a
On 11/08/2014 15:29, Tom Coleman wrote:
>
> I interface a proprietary language with Firebird, Oracle, and Sybase/MS-SQL.
>
> There is never any case where I would want to see std:exception.
>
> Could it be time to start thinking about burying this idea that is looking
> more and more like a sacred
11.08.2014 20:20, Jim Starkey wrote:
> A COM solution would be to have all methods return a COM object (null for
> success if no succes return is required), which could be either a proper
> result object or an error object. But it would require a queryInterface to
> determine which. There othe
On Aug 11, 2014, at 12:06 PM, Lester Caine wrote:
> On 11/08/14 12:53, Alex Peshkoff wrote:
>>> IBPP can
still act as a high-level C++ wrapper, FIBPlus/FireDAC/whatever would
act the same for Delphi, etc. They just need to be ported to the new
core API (whatever it will be).
>> I
Exceptions are clearly an issue. Exception handling is specific to the C++
runtime and can't be handled by other languages. This is specific to COM
however, it applies to all cross language interfaces.
A COM solution would be to have all methods return a COM object (null for
success if no suc
On 11/08/2014 15:00, Dimitry Sibiryakov wrote:
> 11.08.2014 19:55, Adriano dos Santos Fernandes wrote:
>> What's your point?
>No exception is allowed to cross alien boundaries. Only modules built with
> the same
> compiler can throw and catch exceptions. Such modules has no problems you are
11.08.2014 19:55, Adriano dos Santos Fernandes wrote:
> What's your point?
No exception is allowed to cross alien boundaries. Only modules built with
the same
compiler can throw and catch exceptions. Such modules has no problems you are
talking
about, so no hand-made unwind is needed.
--
On 11/08/2014 14:51, Dimitry Sibiryakov wrote:
> 11.08.2014 19:29, Adriano dos Santos Fernandes wrote:
>> Another requirement not yet mentioned for C++ users, are exceptions.
>Worth reading before jumping in:
>
> http://tdm-gcc.tdragon.net/quirks
> https://gcc.gnu.org/wiki/WindowsGCCImprovement
11.08.2014 19:29, Adriano dos Santos Fernandes wrote:
> Another requirement not yet mentioned for C++ users, are exceptions.
Worth reading before jumping in:
http://tdm-gcc.tdragon.net/quirks
https://gcc.gnu.org/wiki/WindowsGCCImprovements
https://www.usenix.org/legacy/events/osdi2000/wiess200
Ok, I got it. I stand corrected.
For the record, when I invented UDFs, neither C++ nor Delphi existed. Hell, C
didn't even have function prototypes.
> On Aug 11, 2014, at 1:58 PM, "Carlos H. Cantu" wrote:
>
> DY> Very questionable requirement. I can easily expect plugins written in
> DY>
Another requirement not yet mentioned for C++ users, are exceptions.
While we can easily just convert IStatus to Exception, if Exception is a
FB class, not even derived from std::exception, it may be completely
inappropriate for users applications.
You know, each C++ project has its own requireme
DY> Very questionable requirement. I can easily expect plugins written in
DY> Delphi.
DY> Dmitry
++1, as it already happens with UDFs (lots of them coded in Delphi).
[]s
Carlos
http://www.firebirdnews.org
FireBase - http://www.FireBase.com.br
DY> 11.08.2014 18:18, Jim Starkey wrote:
>> Since pl
11.08.2014 18:11, Adriano dos Santos Fernandes wrote:
> As C++ doesn't either, to say it's supported, you must test any pair of
> (OS, Architecture), current existent and to be born.
Ok, you can go to GCC developers and ask them if their binary class and VMT
layout
match COM specs by purpose
On 11/08/2014 12:56, Dimitry Sibiryakov wrote:
> 11.08.2014 17:40, Tom Coleman wrote:
>> But if there's no Linux support for COM it would be dead on arrival as far
>> as I would be
>> concerned.
>COM in core is a binary specification for VMT. That's all.
>The rest is just extensions for "u
On 11/08/14 12:53, Alex Peshkoff wrote:
>> IBPP can
>> > still act as a high-level C++ wrapper, FIBPlus/FireDAC/whatever would
>> > act the same for Delphi, etc. They just need to be ported to the new
>> > core API (whatever it will be).
> I agree with this is POV 100%.
I've been following the deb
11.08.2014 17:40, Tom Coleman wrote:
> But if there's no Linux support for COM it would be dead on arrival as far as
> I would be
> concerned.
COM in core is a binary specification for VMT. That's all.
The rest is just extensions for "using anything from anywhere". In our case
they are
no
> On Aug 11, 2014, at 11:49 AM, Adriano dos Santos Fernandes
> wrote:
>
>>
> COM is full of problems:
> - UTF16
> - HRESULT with TLS access to errors
> - No real OOP, just object composing with QueryInterface
> - Ref. counting for all sorts of objects
>
>
This what I mean by ignorance.
COM
11.08.2014 17:26, Tony Whyman wrote:
> Before this goes much further, can someone confirm that COM is
> compatible with Linux. I was always under the impression that it was a
> Windows only technology. Googling the subject does not come up anything
> other than DCOM and a lot of negative comments o
It's been suggested to use Mozilla's XPCOM, which is similar to MSFT COM but
cross platform and with multiple language bindings.
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM
I believe I saw some commentary about Mozilla being a bloated pig, which
might weigh against considering xpc
This COM business has caught me off guard so let me be the first to admit that
I don't know much about it.
But if there's no Linux support for COM it would be dead on arrival as far as I
would be concerned.
(My contact looking to get out of Delphi is also looking for a way to dump
Windows.)
Before this goes much further, can someone confirm that COM is
compatible with Linux. I was always under the impression that it was a
Windows only technology. Googling the subject does not come up anything
other than DCOM and a lot of negative comments on COM.
> COM is full of problems:
> - UTF16
11.08.2014 16:49, Adriano dos Santos Fernandes wrote:
> COM is full of problems:
> - UTF16
> - HRESULT with TLS access to errors
Could you point out where COM specification is forcing usage of UTF16 and
TLS for HRESULT?
--
WBR, SD.
On 11/08/2014 11:49, Adriano dos Santos Fernandes wrote:
> COM is full of problems:
>
Also, the our-IDL compiler may generate COM (complex) wrapper code for
our interfaces (simple).
Doesn't this kill the argument to use something that does not really fit
well as an internal API?
Then if Delphi or
11.08.2014 17:47, Dmitry Yemanov wrote:
> 11.08.2014 18:18, Jim Starkey wrote:
>
>> Since plugins pretty much need to be compiled with the same compiler as the
>> engine
>
> Very questionable requirement. I can easily expect plugins written in
> Delphi.
Agree. More, there is no reason to use s
On 11/08/2014 11:18, Jim Starkey wrote:
> Since plugins pretty much need to be compiled with the same compiler as the
> engine,
Hum??
> and since both COM objects and their clients will be compiled from the
> machine generated interface defintion headers, there is no danger of
> incompatibili
11.08.2014 18:18, Jim Starkey wrote:
> Since plugins pretty much need to be compiled with the same compiler as the
> engine
Very questionable requirement. I can easily expect plugins written in
Delphi.
Dmitry
--
Fir
Since plugins pretty much need to be compiled with the same compiler as the
engine, and since both COM objects and their clients will be compiled from the
machine generated interface defintion headers, there is no danger of
incompatibilities even if there are compilers incompatible with standard
On 08/11/14 16:57, Adriano dos Santos Fernandes wrote:
>>> But there may be more cases, like passing a [in]/out parameter, but may
>>> be possible in C++.
>> May you be a bit more explicit here?
>> If it's about passing interface as parameter - yes, version
>> check/upgrade is needed here.
>> But
Crash running gstat or gbak after encryption is enabled
---
Key: CORE-4516
URL: http://tracker.firebirdsql.org/browse/CORE-4516
Project: Firebird Core
Issue Type: Bug
Components:
<[email protected]>
Message-ID: <[email protected]>
X-Sender: [email protected]
User-Agent: RoundCube Webmail/0.2
On Mon, 11 Aug 2014 15:58:11 +0400, Alex Peshkoff
wrote:
> On 08/11/14 14:52, Mark Rotteveel wrote:
>> IIRC, calling C interfaces from Java
On Mon, 11 Aug 2014 16:48:48 +0400, Alex Peshkoff
wrote:
> On 08/09/14 16:40, Mark Rotteveel wrote:
>> Currently jaybird is handling isc_arg_interpreted the same as
>> isc_arg_string and assumes it is a message parameter for the message of
>> the previous error code.
>>
>> However I was just debug
11.08.2014 14:37, Alex Peshkoff wrote:
>> hide reference counters under
>> the hood as well as dealing with exceptions.
>
> Both not acceptable for us
Why? Do you insist on manual calling of Release by cruelty only or you have
some
technical reasons?
> Will it be OK to return E_NOINTERFACE t
On 11/08/2014 09:45, Alex Peshkoff wrote:
> On 08/08/14 20:47, Adriano dos Santos Fernandes wrote:
>
> At least I have time to answer tech question. What a luck!
Sure.
>> Automatic vtable upgrade is ok for me, provided we have a trust-able and
>> reliable way to add them.
>>
>> Attached a demo fo
11.08.2014 15:36, Dimitry Sibiryakov wrote:
> 11.08.2014 13:39, Vlad Khorsun wrote:
>>As you already 'discovered' absence
>> of not needed QueryInterface in our classes, you should understand why it
>> was not a mistake.
>
> It wasn't a mistake for Delphi only. It failed for FPC.
I don'
On 08/09/14 16:40, Mark Rotteveel wrote:
> Currently jaybird is handling isc_arg_interpreted the same as
> isc_arg_string and assumes it is a message parameter for the message of
> the previous error code.
>
> However I was just debugging the handling of the statusvector for the
> new native client
On 08/08/14 20:47, Adriano dos Santos Fernandes wrote:
At least I have time to answer tech question. What a luck!
> Automatic vtable upgrade is ok for me, provided we have a trust-able and
> reliable way to add them.
>
> Attached a demo for it, search for "upgrade". I implemented dummy
> PluginMo
On 08/11/14 16:25, Dimitry Sibiryakov wrote:
> 11.08.2014 14:03, Adriano dos Santos Fernandes wrote:
>> If you add QueryInterface it should be for QueryInterface purposes, but
>> as you write, it will be a method that only Delphi or FPC will understand.
> Any language/compiler that can work wit
11.08.2014 13:39, Vlad Khorsun wrote:
> As you already 'discovered' absence
> of not needed QueryInterface in our classes, you should understand why it
> was not a mistake.
It wasn't a mistake for Delphi only. It failed for FPC.
--
WBR, SD.
--
11.08.2014 14:15, Alex Peshkoff wrote:
> I also do not understand what's bad in maintaining vtable ourself.
Amount of code needed for poring it to other languages. With standard COM
model it is
enough to define interface. With hand-made VMT one has to write quite big
routines for
filling th
11.08.2014 14:03, Adriano dos Santos Fernandes wrote:
> If you add QueryInterface it should be for QueryInterface purposes, but
> as you write, it will be a method that only Delphi or FPC will understand.
Any language/compiler that can work with COM will understand IUnknown
methods (try to
na
Regression in 3.0: trace reports UPDATES in statistics when doing INSERT into
select . . . from MON$xxx
Key: CORE-4515
URL: http://tracker.firebi
On 08/11/14 16:08, Adriano dos Santos Fernandes wrote:
> On 11/08/2014 08:50, Alex Peshkoff wrote:
>> On 08/11/14 15:18, Jim Starkey wrote:
>>> Adriano, you are arguing that you are right and the rest of the world is
>>> wrong.
>>>
>>> COM is designed so any language can use it, but C++ can use ei
On 11/08/2014 08:50, Alex Peshkoff wrote:
> On 08/11/14 15:18, Jim Starkey wrote:
>> Adriano, you are arguing that you are right and the rest of the world is
>> wrong.
>>
>> COM is designed so any language can use it, but C++ can use either as
>> explicit vectors of method pointer OR as a pure vi
On 11/08/2014 08:25, Dimitry Sibiryakov wrote:
> 11.08.2014 13:02, Adriano dos Santos Fernandes wrote:
>> The current approach of guessing the C++ vtable is compatible between
>> compilers (be it or not about COM classes) is a hack at least for
>> non-Windows platforms who may use different and non
On 08/11/14 14:52, Mark Rotteveel wrote:
> IIRC, calling C interfaces from Java code (using JNI), has been possible
> from Java 1 (or maybe 1.1), but most Java developers don't want to deal
> with native dependencies in their applications. That in itself is the main
> reason to write against a wire
On 08/11/14 15:00, Dmitry Yemanov wrote:
> 11.08.2014 13:45, Mark Rotteveel wrote:
>
>> To illustrate: you seem (?) to be speaking from the perspective of a
>> target audience who use the interface in application development, and where
>> you don't want to deal with all the nitty gritty low-level d
On 08/11/14 15:18, Jim Starkey wrote:
> Adriano, you are arguing that you are right and the rest of the world is
> wrong.
>
> COM is designed so any language can use it, but C++ can use either as
> explicit vectors of method pointer OR as a pure virtual interface. Either
> works, but using it a
11.08.2014 14:25, Dimitry Sibiryakov write:
> I can't remember who did API translation for UIB, but he made a mistake
> using classes
> for declaration.
It was me and it was not a mistake. As you already 'discovered' absence
of not needed QueryInterface in our classes, you should understand
11.08.2014 13:02, Adriano dos Santos Fernandes wrote:
> The current approach of guessing the C++ vtable is compatible between
> compilers (be it or not about COM classes) is a hack at least for
> non-Windows platforms who may use different and non-standard ABIs.
There is nothing to be guessed a
Adriano, you are arguing that you are right and the rest of the world is wrong.
COM is designed so any language can use it, but C++ can use either as explicit
vectors of method pointer OR as a pure virtual interface. Either works, but
using it as a C++ mechanism is very simple and powerful.
Y
11.08.2014 13:02, Adriano dos Santos Fernandes wrote:
> And who says C++ compilers vendors needs to:
> 1) implement vtable-compatible layout in Windows
> 2) implement vtable-compatible layout in non-Windows
Common sense. They already have done that. And quite a few of non-C++
compilers vendors
Adriano, this is a completely inappropriate response. If you think he is
wrong, you must explain exactly why he is wrong. While reasoning carries
weight, person opinions do not.
So, if you think he is wrong, olease elaborate.
> On Aug 11, 2014, at 7:48 AM, Adriano dos Santos Fernandes
>
On 11/08/2014 07:54, Dimitry Sibiryakov wrote:
> 11.08.2014 12:47, Adriano dos Santos Fernandes wrote:
>> The hack approach dependent on compilers details is the one we use
>> currently.
>Currently used pure abstract classes are exactly like in COM. And "The
> Component Object
> Model specifi
11.08.2014 13:45, Mark Rotteveel wrote:
> To illustrate: you seem (?) to be speaking from the perspective of a
> target audience who use the interface in application development, and where
> you don't want to deal with all the nitty gritty low-level details, here
> IBPP is probably a good fit (but
11.08.2014 12:47, Adriano dos Santos Fernandes wrote:
> The hack approach dependent on compilers details is the one we use
> currently.
Currently used pure abstract classes are exactly like in COM. And "The
Component Object
Model specifies a *programming-language-independent _binary standard_
<[email protected]>
Message-ID:
X-Sender: [email protected]
User-Agent: RoundCube Webmail/0.2
On Sun, 10 Aug 2014 12:15:33 +0200, Dimitry Sibiryakov
wrote:
> was a lot of languages (including Java and .NET in their early days)
that
> were unable to use good old C interface. They
On 11/08/2014 06:25, Molnár Attila wrote:
> So this Interface is not designed and made for clinet component
> developers and communicatin with server but just for Firebird engine
> inside use?
> In that case just do what you want. ;)
>
>
He's totally wrong on this!
Adriano
---
On 11/08/2014 06:04, Kjell Rilbe wrote:
> Den 2014-08-10 12:04 skrev Dmitry Yemanov såhär:
>> 10.08.2014 13:55, Reinier Olislagers wrote:
>>
>>> However, apparently FB devs don't think it's important to keep it in
>>> sync with the C++ interface - even if third parties could submit patches
>>> for
On 11/08/2014 05:43, Alex Peshkoff wrote:
>
> Technical issues can, in fact, be discussed with more depth than "+1". In
> fact, everything in engineering is a tradeoff, and tradeoffs can be
> reasonably balanced and discussed. But dismissing something that you don't
> agree with as "abstract b
On Mon, 11 Aug 2014 11:14:28 +0100, Tony Whyman
wrote:
> Mark,
>
> I expressed concern last week that there was too much "heat" on the list
> and got told that passion was good - you can't win :(
Passion is good, until it becomes an obstacle.
> You said "Personally I'd say that Firebird should
Mark,
I expressed concern last week that there was too much "heat" on the list
and got told that passion was good - you can't win :(
You said "Personally I'd say that Firebird should at minimum have a
low-level API (which the current ibase.h provides, although it has some
annoyances)".
In a nuts
On Mon, 11 Aug 2014 09:18:58 +0100, Tony Whyman
wrote:
> Firebird already has a C++ Interface that is widely if not universally
> used by C++ Developers (including myself) to access the Firebird API.
> This is IBPP. IMHO, it is well designed, stable and fit for purpose. It
> compares well with sim
So this Interface is not designed and made for clinet component
developers and communicatin with server but just for Firebird engine
inside use?
In that case just do what you want. ;)
On 2014.08.11. 11:05, Dimitry Sibiryakov wrote:
> Remember, that new API wasn't designed as a public API. It w
Allow Firebird Service to be started as automatically (delayed) in Windows
(starting at Vista)
--
Key: CORE-4514
URL: http://tracker.firebirdsql.org/browse/CORE-4514
Den 2014-08-10 12:04 skrev Dmitry Yemanov såhär:
> 10.08.2014 13:55, Reinier Olislagers wrote:
>
>> However, apparently FB devs don't think it's important to keep it in
>> sync with the C++ interface - even if third parties could submit patches
>> for that.
>>
>> So in effect, new FB (features) wil
11.08.2014 10:59, Molnár Attila wrote:
> So basicly pure Object based API is off the table.
> Interface based might be good, and we ended up with COM.
Funny that you said that. Following article makes clear that they are
exactly the same:
http://www.codeproject.com/Articles/338268/COM-in-C
--
11.08.2014 10:49, Molnár Attila wrote:
> #1 : API call creates object and returned to host
> - in this case object has to be readonly (at least buffer like fields)^1
> - host has to support reference counting^2
>
> #2 : API call parameterised by a host created object
> - see #1
>
> 1
BTW API and host has different (can't have) class information (class
pointer, VMT, etc..) for the same object, so by definition they not
communicate with the SAME class. The classes could have same name,
and can act the same, but the equality operation would give you
FALS
Lets see the next scenatios
#1 : API call creates object and returned to host
- in this case object has to be readonly (at least buffer like
fields)1
- host has to support reference counting2
#2 : API call parameterised by a host created object
11.08.2014 10:38, Alex Peshkoff wrote:
> Next, COM means UTF16 (at least on windows). Do we want to change our
> favorite UTF8 to UTF16 on every call? We decided that we do not.
>
> And last issue. IUnknown alone is far not a full COM, at least
> automation is needed. I do not know an easy way to h
On 08/08/14 20:40, Jim Starkey wrote:
>> On Aug 8, 2014, at 9:05 AM, Adriano dos Santos Fernandes
>> wrote:
>>
>>> On 08/08/2014 08:52, Jim Starkey wrote:
>>>
>>> So, if I understand your original goals, again as an outsider, I would have
>>> to say that your current interface proposal does not
On 08/09/14 01:30, Jim Starkey wrote:
> Isn't COM a natural technology for plugins? Load a module, lookup the query
> interface interface, then probe for known interfaces. If one is found, it
> identifies both the formal interface and, by implication, the type of plugin.
>
> By definition, COM
Firebird already has a C++ Interface that is widely if not universally
used by C++ Developers (including myself) to access the Firebird API.
This is IBPP. IMHO, it is well designed, stable and fit for purpose. It
compares well with similar libraries such as MySQL++ and Oracle OCCI.
On the other ha
11.08.2014 9:12, Molnár Attila wrote:
> #3 : client & plugin OO API
> - only C++ developers can use is (small part of the whole user base pie)
It is not true. Common Object Model is supported not only in C++ compilers.
Current
problem is the result of two factors:
1) Our object hierarchy
Hi!
Some note from an outsider view.
#1 : both client & plugin API MUST support C-tyle
API (lowest common dominator)
- standard data types, zero terminated strings,
pointers/handles, records, stdcall/cdecl functions, NO
objects/interfaces
- m
89 matches
Mail list logo
