MPA1.0 - WM6.1 upgrade - reduction of application partition

I wanted to pass along the following information on the future WM6.1 release for our MPA1.0 products.

Due to the increased OS size of WM6.1 compared to WM5.0, the super persistant store/clean boot persistant (AKA "Application" partition) will need to be reduced from the current 24MB to somewhere between 7MB - 10MB.

Even though there does not look like there will be mcuh we can do to improve that number, I would still like some feedback on whether you believe this will have a major impact on a customer's typical deployment.

Thanks,

Tom Cassar
Allan Herrod
Tom; This concerns me quite


Tom;

This concerns me quite a bit.
A full-up install of all MSP 3.x functionality takes about 2MB of space in \Application.
That is less than 10% of 24MB.
But that goes up to 20-30% of 7-10MB.

The VPN client from Bluefire is also around 2MB.
So, similar figures would apply.

Customers continue to demand that many things be installed in a manner that is clean boot persistent.
This is partially inertia and partially due to real world situations.
Note that the need to do a clean boot to install many patches and the need to keep content persistent across an OS update (such as is needed to apply Fusion updates and keep working) means that \Application space is at a premium.

I think we need to be very careful to understand the tradeoffs between persistent and super-persistent storage as they relate to what customers believe (rightly or wrongly) NEEDS to be clean boot peristent.  If we are providing a system that no longer has sufficient space to make some things clean boot persistent, we need to start early to assess the impact this will have on the field.

Allan

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Lawrence Annunziata
Team,While I understand that


Team,


While I understand that this is a necessity because of the larger OS this will impact customers. If pressed more customers will need to stay on Win Mobile 5 because their applications need more storage than is available! We will need to keep WM5 around and ensure that we push WM6/6.1 only on gear designed for it.

What does the rest of the group think?

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Robert Galvin
Does anyone know how this

Does anyone know how this compares against the competition (i.e will this be used against us)?
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Anthony Ambler
I agree with the previously

I agree with the previously comments made already on this post that this will have a very large impact on most of my customers. Most customers will have to stay on WM5 or be forced to rewrite applications to run from alternative storage like SD cards if they will upgrade to WM6.1.

1) As Rob posted, where do our competitors stand on this issue? I'm assuming they are in the same situation as we are but we need to know for sure.

2) Are we going to rethink our WM5 strategy and provide at least 1 or 2 more maintenance releases to compensate for all of the customers who were planning on upgrading to WM6.1 but now will be forced to stay on WM5?

Tony Ambler
Vote: 
Vote up!
Vote down!

Points: 1

You voted ‘up’


Mark Mann
Team, I also have concerns

Team,

I also have concerns since I have customers already using an SD card with their application and database which leaves very little space left over.  I was under the impression there was a limit as to what size SD cards were able to support.  So upgrading the SD card may not be an option or if it's an option then it will create an additional cost and logistics for devices already rolled out.

Lastly, will new WM6.1 osupdate now require a SD card if the Application folder is limited or the Temp folder will be able to handle updates via AirBeam/MSP/Avalanche?

Mark
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Damian Stock
Tom, I have at least two

Tom,

I have at least two customers who are using MSP to deploy .net applications onto their devices. They expect these applications to be cold boot persistent as this is one of the main reasons for deploying MSP. Their current application directoy usage is around 22 Mb so I cannot see how they will be able to deploy these applications under a WM6.1 O/S. They especially need this persistence as it would take quite a few minutes to bring a device back into operation if they needed to download all of their components after a cold boot.

Maybe these customers will never want to upgrade to WM6.1 but it makes it difficult to promote the MSP architecture to new device customers with this emerging persistent storage limitation. I can see that this is not necessarily our fault but I would hope that we could come up with a solution that does not involve using card storage, especially as some customers require their card slot for other purposes.

Thanks,

Damian
Vote: 
Vote up!
Vote down!

Points: 1

You voted ‘up’


Marc Fluhrer
Major impact. There are

Major impact. There are customers running more than Telnet.

A few of my customers need to load .Net and SQL on their handhelds, this is about 4 - 5mb, along with MSP they would be getting pretty maxed out. And since they keep these files on the terminal, just in case, they would be way beyond 7mb.

Isn't WM6.X come preloaded with .Net and SQL? If so, maybe this is an even exchange for these customers. But still, not enough to have any data stored for the application to use.

Tom, are there any other software applications being lumped in by Microsoft that are taking up the space? Or is it just all new OS features? I would be willing to drop Pocket Word and Excel for more space.
Vote: 
Vote up!
Vote down!

Points: 1

You voted ‘up’


Horst Anderlohr
We had some customer

We had some customer compaining having to less Application Memory on MC50 after upgrating them to WM05. Finaly we "fixed" this asking them to use a SD card. All over all 7 or 10 MB is to less and will effekt again some customers. Beside having more flash memory on MPA 1.5 or 2.0 I do not see a big chance to free up more memory on MPA 1.0 products.
I like the isea from Marc, how many memory could be saved dropping some Applications generally not needed? 
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Richard Linsley-Hood
Please note that the

Please note that the /Application folder is SUPER PERSISTENT, i.e. survives a Clean Boot. All other folders will not be affected by this change, /Temp, /Program Files, /Widnows, etc.

Therefore any 'normal' instalation that takes place from cab files should not be affected. They would only be affected if they wanted to store those cab files in the /Application folder and thus be able to update the OS without updating the rest of their install. This should be a small requirement in general.

In most cases the competition do not offer Super Persistent storage so this is a plus for us in general.

Richard LH
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Dimitri Zantidis
Tom, With the release of WM6

Tom,

With the release of WM6.1, we also need to provide a white paper which shows, with practical examples, how to deploy applications using the alternative storage of a memory card.  The link to the white paper should be on the same page where you can download (or get the license) of WM6.1, so everyone who intends to download it can see and have easy access also to the white paper.

The white paper should describe through specific examples the alternative deployment ways, and capture all general categories the \Application folder is being used so far for initial deployments.  Some examples should include:
- Deployment of settings using registry files
- Deployment of cpf, and cab files
- Promote the usage of StartUp Control application by providing a specific example how you could deploy a cab file that is stored in a memory card.
There are maybe more other general ways of deployment settings and applications that I'm not aware and the field should also provide feedback on that.

I see more issues coming with MSP, as I would prefer the amount of memory we give to customers (7-10MB) to remain available for them only.  If they also use MSP then the available memory will vary, depending on the requirements of MSP, and this at some point and unexpectedly may create space problems. For me the idea of MSP and customer sharing an even less available persistent memory is not very attractive.  I  would prefer if we solve the problem providing an alternative location for MSP and allow the customers to use all of persistent storage for themselves.

Finally, I like to have the same functionality with \Storage Card\StartUp folder as we have with \Application\StartUp folder. A WM6.1 device looks for it and if it exists it attempts to run all of its contents (registry, cpf, cab, exe and other files).

Dimitri Zantidis
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Robert Galvin
Tom, this will be an issue

Tom, this will be an issue for many of our customers.  Most of my accounts use the application partition to load applications and backup install cab files.  Some use quite a bit of space, i.e. CF, SQL, and application.  The reduced foot print will force these customers to stay on WM5.0.  Not sure what other options we have but we need to be very clear on what we are proposing and what alternatives we will have – using an SD card is an option but not one well received by our customers, cost and performance have always been an issue.


 


HM


 



Hector Meza

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Carl Pearson
This is what I will tell my


This is what I will tell my customers ....

If you are wishing to upgrade a 64Meg NOR flash device to WM 6.1, please consider that the \Application will shrink to 6-meg.  This may or may not require that additional storage be installed as a SDMMC card.

We encourage usage of a high-quality, high-speed SDMMC card, preferably with >20meg/sec read and write speeds, depending on performance requirements.

 Carl ~ Texas   
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Thomas Cassar
Note that WM6.1 has .NET

Note that WM6.1 has .NET Compact Framework and SQL Server Compact Edition already in the OS image.
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Glenn Sayer
One more thing to keep in

One more thing to keep in mind before you send your customers down the SD card path is that this storage is not resident and needs to be loaded at startup.  This causes the card to not be present for a short period of time during startup.  This has caused issues with some of my customer that write to the SD card before it is loaded causing a “Storage Card 2” to be created for the actual SD card.  This name change will goof you up. 


 


The only way to resolve this issue is to have MS or Moto create a way for the SD to stay resident like internal memory making it 100% available.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


JON PREEDY
I'd agree with Richard: since

I'd agree with Richard: since we have a persistent model with WM5 the super-persistent store is less of a critical thing for me. As long as we have somewhere to drop registry modifications and CAB files and the like that will kick on a cold boot I'm not too troubled.

That said, totally onside with Marc and Damian as well that in some cases (particularly MSP sites with complex apps) this could be a deal-breaker.

There is also the perception issue that less is, well, less. This is going to be a hard sell to the partner ecosystem and will most likely dissuade some prospects from migrating to 6.1. If we could get some competitive info about the features/benefits and tradeoffs of migrating to 6.1, I think that would be super-handy.
-JP
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Mark Harrer
This is a significant

This is a significant reduction in the amount of space in the application folder and will create major issues. At a time when vendors are adding more and more space to their devices, it would hurt us treemendously to do this. Furthermore, this would create problems with our software providers who develop applications for our terminals.

I would suggest that the development team consider other alternatives to this solution.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Richard Linsley-Hood
As the application memory

As the application memory (Virtual Memory really) footprint of 6.1 is so much better than the previous offerings (even 6.0 and below) the option to not move to it is not possible. Apart from anything else everbody would sell against us based on us not moving to the latest Microsoft offering.

As the ONLY way that we can move to 6.1 is to reduce the super persistent Application folder size again there is no choice (This is because at the end of the day the memory available is fixed by the physical chips on board).

We will not need either Compact Framework of SQL server cabs to be deployed into/from the Application folder as these are already included in the 6.1 OS, so there are two cabs of large size which could be considered to be on top the reduced Application folder size (sqlce.ppc.wce5.armv4i.CAB is 716Kb, NETCFv2.ppc.armv4.cab is 5.5Mb so some 6.2Mb in total).

Rememer that the Super Persistent Application folder is an extra we provide that other vendors do not. It is just, going forward, it will not be as big as it was previously.

Richard LH
Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Log in to post comments