coapp-developers team mailing list archive

["Trevor Dennis" <trevor@xxxxxxxxxxxxx>]

XP/2003 don't support symbolic links at all.  Will junctions (hard links) be
good enough?  

 

Don't discount XP and 2003 as old operating systems.  Coming from the
corporate world (EDS and now HP), we have 60%+ desktops still on XP SP2/SP3
and probably 90%+ on Windows 2003.  Some servers still on Windows 2000, and
just a few are starting to move to 2008 as new hardware is purchased.  This
is probably comparable to every other corporation out there (other than
Microsoft itself).

 

If this project is going to work, it has to support XP SP3 at a minimum.  At
least as long as Microsoft is supporting XP SP3.  I'd say even SP2 right now
but they're dropping regular support for that this summer.

 

Trev.

 

 

From: coapp-developers-bounces+trevor=dennis-it.com@xxxxxxxxxxxxxxxxxxx
[mailto:coapp-developers-bounces+trevor=dennis-it.com@xxxxxxxxxxxxxxxxxxx]
On Behalf Of Garrett Serack
Sent: Wednesday, April 07, 2010 10:22 AM
To: Rivera, Rafael; coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] Another kind of package

 

Arg!

 

We're absolutely trying to avoid relying on LUAFS (the component that
silently virtualizes writes out of [\Program Files]). The purpose of that is
for backward app compatibility -future work should definitely avoid the use
of that.  Anyway I'm pretty sure that Windows Server 2003 R2 is in active
support until December 2015.

 

I like the idea of <vendor>\<app>\<version> too, but one of my goals was to
have the ability to symlink the current version to a predictable
well-known-path, and I'd like to use the same pattern for all aspects of
location determination. (web apps, desktop apps, libraries, docs, etc)

 

I've sketched out some ideas:

 

The first (under option1), was my original idea-well-known-path points to a
specific sibling version. This is nice,  predictable, and easy to change a
path somewhere to switch over to a specific version if required, otherwise
the 'unversioned' path is authoritative. This is similar to common
conventions in Linux.

 

The second (under option2) doesn't present an obvious way to have an
authoritative version, short of making a 'current' symlink in the same
directory.

 

The third (under option3) is kind of a compromise-there still is an
authoritative version, and all the different versions roll up under a common
directory.  I'm not very keen on it, but it's not bad.

 

 

+---option1

|   +---openssl         -- symlink to openssl-0.98j

|   +---openssl-0.98i

|   +---openssl-0.98j

|   +---zlib            -- symlink to zlib-1.23

|   +---zlib-1.23

|   +---zlib-1.25

|

+---option2

|   +---openssl

|   |   +---0.98i

|   |   +---0.98j

|   +---zlib

|       +---1.23

|       +---1.25

|

+---option3

    +---openssl         -- symlink to [openssl]\0.98j

    +---zlib            -- symlink to [zlib]\1.25

    +---[openssl]

    |   +---0.98i

    |   +---0.98j

    +---[zlib]          

        +---1.23

        +---1.25

 

 

Ideas?

 

Garrett Serack | Open Source Software Developer | Microsoft Corporation 

I don't make the software you use; I make the software you use better on
Windows.

 

From: coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx
[mailto:coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx]
On Behalf Of Rivera, Rafael
Sent: Tuesday, April 06, 2010 6:46 PM
To: coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] Another kind of package

 

I'm new to the conversation, so I don't have quoted material -- apologies.

Program Files\ hosting
Starting with Windows Vista and Windows Server 2008, we have virtualization
that silently takes over and redirects (for appcompat reasons) writes to the
caller's virtual application store. With Windows XP and Windows Server 2003
fading away, is hosting in Program Files\ really a problem? I think we can
safely assume that users with this type of virtualization turned off within
the candidate OSes are super advanced/asking for trouble and therefore
shouldn't be considered in the design process. It's impossible to please
everyone.

Directory structure
I like Elizabeth's approach of dropping versions (e.g. 1.0, 1.1) into an
authoritative <vendor>\<app> folder. I'd imagine this is neater, especially
when dealing with faster updating applications (or lots of installed
applications).

/rafael