coapp-developers team mailing list archive

[Garrett Serack <garretts@xxxxxxxxxxxxx>]

Well, I wouldn't worry about inheriting limitations.

I'm well aware of several limitations in XP and 2k3 that would otherwise cause issues, but I'm confident at this point and time that we can design *for* Windows 7 & Server 2k8 and still provide an acceptable down-level experience.

If there is a problem with the design that will not function on XP and 2k3, but a workaround for XP and 2k3 would solve the issue without breaking the design for Vista+ operating systems, then we don't need to change the design. (I've already documented the lack of file-symlinks in XP, which requires a 'copy' behavior instead of linking--not perfect, but perfectly functional)

G

-----Original Message-----
From: coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx [mailto:coapp-developers-bounces+garretts=microsoft.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Rivera, Rafael
Sent: Wednesday, April 07, 2010 10:46 AM
To: coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] Another kind of package

I understand legacy OSes are still in play, our product is actually
still hosted on Windows Server 2003, for various bureaucratic reasons.

But from my experience, these legacy servers/desktops are set up in very
specific, static configurations that won't be a candidate for CoApp use.
I'm just a little worried CoApp will be designed with OS-driven
limitations in mind only to have these OSes go away when CoApp reaches
maturity. Or worse, more people will use these OSes because of CoApp ;)

/rafael


On 4/7/2010 12:57 PM, Trevor Dennis wrote:
> 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
> 
> 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~coapp-developers
> Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~coapp-developers
> More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~coapp-developers
Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~coapp-developers
More help   : https://help.launchpad.net/ListHelp