I'd just like to remind everyone that Visual Studio Express users don't get
plugins.
On Thu, Apr 15, 2010 at 10:57 AM, Garrett Serack wrote:
> Hmm.
>
> [Longer Term] a package browser in Visual Studio that gets a list of
> library packages from the repositories.
>
> G
>
>
On Fri, Apr 16, 2010 at 7:49 PM, Olaf van der Spek wrote:
> 2010/4/16 Pierre Joye :
>> I'm not sure the development files should end in a common directory.
>> As it has been mentioned in this thread, it will not be possible to
>> have multiple versions of a library. However I'm really not sure tha
2010/4/16 Pierre Joye :
> I'm not sure the development files should end in a common directory.
> As it has been mentioned in this thread, it will not be possible to
> have multiple versions of a library. However I'm really not sure that
> the development files and the distribution package should fo
Anyone can push malware through Windows Update with little effort.
Microsoft doesn't perform a useful security audit of published binaries;
they simply rely on the fact that signing requires a slew of IDs and
secret handshakes which are difficult to fake (i.e. remain an anonymous
baddie).
I think
hi Garrett,
2010/4/15 Garrett Serack
>
> Currently, the plan is to have something like this for common files
> (bin/doc/include/lib):
>
>
> └───Program Files [and Program Files (x86)]
>
> └───Common Files -- already present in Windows installations
>
> └───CoApp
>> Suppose it contains a trojan.
Very very very very difficult to pull off with signed binaries, and no exes
with a shared library package.
You're talking about the publisher screwing up and builds a compromised library
and signing it. Well, that indeed is what a killbit system is for.
I find
On Fri, Apr 16, 2010 at 7:08 PM, Garrett Serack wrote:
> What specifically do you mean by compromised?
Suppose it contains a trojan.
> If you mean that a package is published and someone is trying to pass it off
> as someone else's package, well that's why we have a requirement for a
> publish
What specifically do you mean by compromised?
If you mean defective, well, that is a small potential problem. It is in any
system.
If you mean that a package is published and someone is trying to pass it off as
someone else's package, well that's why we have a requirement for a publisher
to di
On Fri, Apr 16, 2010 at 6:48 PM, Garrett Serack wrote:
> And really, that's how Windows Update works anyway... we might as well learn
> from that.
WU doesn't install code published by third-parties, does it?
> Without that, we'd be forced to Admin-only installs of shared libraries,
> since the
It looks like IA64 is going to have an end-of-life on Windows, so that
certainly has a lower priority.
And I really can't argue much with either of your points, and I don't see a
compelling reason why we should, other than "wouldn't it be nice if..."
G
Garrett Serack | Open Source Software De
LOL.
That's why we'll be doing a security audit at many checkpoints in the
development of the client.
And really, that's how Windows Update works anyway... we might as well learn
from that.
Without that, we'd be forced to Admin-only installs of shared libraries, since
there is no way to handl
On Fri, Apr 16, 2010 at 6:31 PM, Garrett Serack wrote:
> I'm not aware of a way to have user installs of WinSXS libraries. By
> definition, they are system level.
>
> However, we could just require the installer client to be installed and setup
> as admin, and have it run its service at a higher
On 4/16/2010 11:25 AM, Olaf van der Spek wrote:
>
> Speaking about Program Files, is there a goal to support per-user
> installs (so not requiring admin access)?
+1
___
Mailing list: https://launchpad.net/~coapp-developers
Post to : coapp-developer
I'm not aware of a way to have user installs of WinSXS libraries. By
definition, they are system level.
However, we could just require the installer client to be installed and setup
as admin, and have it run its service at a higher level, so shared libraries
can be installed (which aren't end-u
On 4/16/2010 11:16 AM, Garrett Serack wrote:
> Yes, that's pretty much it.
>
> Well, really:
>
> C:\program files\common files\CoApp\...
>
> And
>
> C:\program files (x86)\common files\CoApp\...
>
> See http://coapp.org/Blueprints/Packages/4.Shared_Library_Packages
>
> Although, I just saw a
On Fri, Apr 16, 2010 at 6:13 PM, Garrett Serack wrote:
> Um, both can be *concurrently* installed, they have different target
> directories;
>
> It sounds like sharing anything between them isn't worth it; I'd rather not
> have to over-engineer multi-arch config.h files, and the ilk.
>
> So, nev
On Fri, Apr 16, 2010 at 6:11 PM, William A. Rowe Jr. wrote:
> On 4/16/2010 11:07 AM, Olaf van der Spek wrote:
>> On Fri, Apr 16, 2010 at 6:04 PM, Garrett Serack
>> wrote:
>>> Well, that was the idea...
>>>
>>> I suppose that typical config.h files might differ between the two, but
>>> other tha
Yes, that's pretty much it.
Well, really:
C:\program files\common files\CoApp\...
And
C:\program files (x86)\common files\CoApp\...
See http://coapp.org/Blueprints/Packages/4.Shared_Library_Packages
Although, I just saw a problem with that.
***
A developer on a 3
Um, both can be *concurrently* installed, they have different target
directories;
It sounds like sharing anything between them isn't worth it; I'd rather not
have to over-engineer multi-arch config.h files, and the ilk.
So, nevermind. :D
Garrett Serack | Open Source Software Developer | Micr
On 4/16/2010 11:07 AM, Olaf van der Spek wrote:
> On Fri, Apr 16, 2010 at 6:04 PM, Garrett Serack
> wrote:
>> Well, that was the idea...
>>
>> I suppose that typical config.h files might differ between the two, but
>> other than that, I can't think of a case where the header files would be
>> d
On 4/16/2010 11:04 AM, Garrett Serack wrote:
> Well, that was the idea...
>
> I suppose that typical config.h files might differ between the two, but other
> than that, I can't think of a case where the header files would be different.
>
> But, it's not a *requirement*, just a
> lack-of-caffein
On Fri, Apr 16, 2010 at 6:04 PM, Garrett Serack wrote:
> Well, that was the idea...
>
> I suppose that typical config.h files might differ between the two, but other
> than that, I can't think of a case where the header files would be different.
>
>
> But, it's not a *requirement*, just a
> lack
Well, that was the idea...
I suppose that typical config.h files might differ between the two, but other
than that, I can't think of a case where the header files would be different.
But, it's not a *requirement*, just a lack-of-caffeine-induced-delirium-idea...
G
Garrett Serack | Open Source
On Fri, Apr 16, 2010 at 5:38 PM, William A. Rowe Jr. wrote:
> On 4/16/2010 9:59 AM, Garrett Serack wrote:
>> For Library packages (static and dynamic) I’m wondering if we shouldn’t
>> just put both variants in the same package—still installing the WinSxS
>> binaries appropriately, and putting the
Ok.
What do you think about having the client service default to installing
both--separately, but transparently , when a library is installed?
That would be a configurable setting.
Garrett Serack | Open Source Software Developer | Microsoft Corporation
I don't make the software you use; I ma
On 4/16/2010 9:59 AM, Garrett Serack wrote:
> For Library packages (static and dynamic) I’m wondering if we shouldn’t
> just put both variants in the same package—still installing the WinSxS
> binaries appropriately, and putting the .lib files in the correct spot.
>
> This would actually conserve
For Library packages (static and dynamic) I'm wondering if we shouldn't just
put both variants in the same package-still installing the WinSxS binaries
appropriately, and putting the .lib files in the correct spot.
This would actually conserve disk-space, since the x64 and x86 versions of the
p
I've added a new section to the Wiki, where any registered wiki user can add an
end-user or developer story (aka scenario) that they would like to see covered
in CoApp.
These are not designs but rather, ideas of things we'd like to be able to do.
Things you find in here may or may not become
Howdy ya'll,
>> For example, I may need to install more than one of the same application on
>> a system in different locations
Understandable, and I'd recommend symlinks.
>> Or, I may want to have a third-party application bundled with one I'm
>> distributing,
Bundling can be provided for wit
Although deliberate customizations are nice-to-haves, CoApp (to my
understanding) is not your average application installation. It wishes to
be viewed as an open-source oriented add-on to Windows environments --
somewhere between a regular software application and the base Windows files.
Heck, it
In Windows applications it's a gernell ability to choose the root directory for
your application. I think it should be possible for CoApp users to set this
base directory in order to be most flexible. But for the general user, the
standard directories for Windows should be uses as the default be
31 matches
Mail list logo
