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....@lists.launchpad.net > [mailto:coapp-developers-bounces+trevor=dennis-it....@lists.launchpad.net] > On Behalf Of Garrett Serack > Sent: Wednesday, April 07, 2010 10:22 AM > To: Rivera, Rafael; [email protected] > 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....@lists.launchpad.net > [mailto:coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net] > On Behalf Of Rivera, Rafael > Sent: Tuesday, April 06, 2010 6:46 PM > To: [email protected] > 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 : [email protected] > Unsubscribe : https://launchpad.net/~coapp-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
