[Year 12 SofDev] RE: Kevin's solution to VB6 Upgrade
Russell Quinn
QN at boxhillhs.vic.edu.au
Fri Sep 5 10:20:12 EST 2008
Thanks Kev,
I will get the technician to try it.
much obliged,
Russell Quinn
Mailto: qn at boxhillhs.vic.edu.au
From: sofdev-request at edulists.com.au
Sent: Fri 5/09/2008 9:27 AM
To: sofdev at edulists.com.au
Subject: sofdev Digest, Vol 43, Issue 6
Send sofdev mailing list submissions to
sofdev at edulists.com.au
To subscribe or unsubscribe via the World Wide Web, visit
http://www.edulists.com.au/mailman/listinfo/sofdev
or, via email, send a message with subject or body 'help' to
sofdev-request at edulists.com.au
You can reach the person managing the list at
sofdev-owner at edulists.com.au
When replying, please edit your Subject line so it is more specific
than "Re: Contents of sofdev digest..."
Today's Topics:
1. MS blog engineering Windows v7 (stephen at melbpc.org.au)
2. Upgrade from VB6 to VB.Net (Russell Quinn)
3. Re: Upgrade from VB6 to VB.Net (Kevin Feely)
----------------------------------------------------------------------
Message: 1
Date: Thu, 4 Sep 2008 10:37:54 GMT
From: stephen at melbpc.org.au
Subject: [Year 12 SofDev] MS blog engineering Windows v7
To: link at anu.edu.au
Cc: sofdev at edulists.com.au, offtopic at edulists.com.au
Message-ID: <20080904103754.317066E3 at eagle.melbpc.org.au>
Microsoft: Engineering Windows 7
Welcome to our blog dedicated to the engineering of Microsoft Windows 7
http://blogs.msdn.com/e7/
Friday, August 29, 2008 12:00 AM
Boot Performance
For Windows 7, we have a dedicated team focused on startup performance,
but in reality the effort extends across the entire Windows division and
beyond. Our many hardware and software partners are working closely with
us and can rightly be considered an extension to the team.
Startup can be one of three experiences; boot, resume from sleep, or
resume from hibernate.
Although 'resume from sleep' is the default, and often 2 to 5 seconds
based on common hardware and standard software loads, this post is
primarily about 'boot' as the experience has been commented on frequently.
For Windows 7, a top goal is to significantly increase the number of
systems that experience very good boot times. In the lab, a very good
system is one that boots in under 15 seconds.
For a PC to boot fast a number of tasks need to be performed efficiently
and with a high degree of parallelism.
Files must be read into memory.
System services need to be initialized.
Devices need to be identified and started.
The users credentials need to be authenticated for login.
The desktop needs to be constructed and displayed.
Startup applications need to be launched.
Because systems and configurations differ, boot times can vary
significantly. This is verified by many lab results, but can also be seen
in independent analysis, such as that conducted by Ed Bott.
Sample data from Eds population of systems found that only 35% of boots
took less than 30 seconds to give control to the user. Though Eds data is
from a small population, his data is nicely in line with what were
observing. Windows Vista SP1 data also indicates that roughly 35% of
systems boot in 30 seconds or less, 75% of systems boot in 50 seconds or
less.
The Vista SP1 data is real world telemetry data. It comes to us from the
very large number of systems (millions) where users have chosen to send
anonymous data to Microsoft via the Customer Experience Improvement
Program. http://www.microsoft.com/products/ceip/EN-US/default.mspx
>From our perspective, too few systems consistently boot fast enough and we
have to do much better.
Obviously the systems that are greater than 60 seconds have something we
need to dramatically improve whether these are devices, networking, or
software issues. As you can see there are some systems experiencing very
long boot times. One of the things we see in the PC space is this
variability of performancevariability arises from the variety of choices,
and also the variety of quality of components of any given PC experience.
There are also some system maintenance tasks that can contribute to long
boot times. If a user opts to install a large software update, the actual
updating of the system may occur during the next boot. Our metrics will
capture these and unfortunately they can take minutes to complete.
Regardless of the cause, a big part of the work we need to do as members
of the PC ecosystem is address long boot times.
In both Eds sample and our telemetry data, boot time is meant to reflect
when a machine is ready and responsive for the user. It includes logging
in to the system and getting to a usable desktop. It is not a perfect
metric, but one that does capture the vast majority of issues.
On Windows 7 and Vista systems, the metric is captured automatically and
stored in the system event log. Eds article covers this in depth.
We realize there are other perceptions that users deem as reflecting boot
time, such as when the disk stops, when their apps are fully responsive,
or when the start menu and desktop can be used.
Also, Post Boot time (when applications in the Startup group run and
some delayed services execute), the period before Windows boot is
initiated, and BIOS time can be significant. In our efforts, weve not
lost sight of what users consider being representative of boot.
Before discussing some of our Windows 7 efforts, wed like to point out
there is considerable engagement with our partners underway. In scanning
dozens of systems, weve found plenty of opportunity for improvement and
have made changes. Illustrating that, please consider the following data
taken from a real system.
As the system arrived to us, the off-the-shelf configuration had a ~45
second boot time. Performing a clean install of Vista SP1 on the same
system produced a consistent ~23 second boot time. Of course, being a
clean install, there were many fewer processes, services and a slightly
different set of drivers (mostly the versions were different). However, we
were able to take the off-the-shelf configuration and optimize it to
produce a consistent boot time of ~21 seconds, ~2 seconds faster than the
clean install because some driver/BIOS changes could be made in the
optimized configuration.
For this same system, it is worth noting the resume from sleep time is
approximately 2 seconds, achieving a nearly instant on experience. We do
encourage users to choose sleep as an alternative to boot.
As an example Windows 7 effort, we are working very hard on system
services. We aim to dramatically reduce them in number, as well as reduce
their CPU, disk and memory demands.
Our perspective on this is simple; if a service is not absolutely
required, it shouldnt be starting and a trigger should exist to handle
rare conditions so that the service operates only then.
Of course, services exist to complete user experiences, even rare ones.
Consider the case where a new keyboard, mouse or tablet HW is added to the
system while it was off. If this new HW isnt detected and drivers
installed to make the HW work during startup, then the user may not be
able to enter their credentials and log into the machine. For a given
user, this may be a very rare or never encountered event.
For a population of 100s of millions of users, this can happen frequently
enough to warrant having mechanisms to support it. In Windows 7, we will
support this scenario and many others with fewer auto start services
because more comprehensive service trigger mechanisms have been created.
As noted above, device and driver initialization can be a significant
contributor as well. In Windows 7, weve focused very hard on increasing
parallelism of driver initialization. This increased parallelism decreases
the likelihood that a few slower devices/drivers will impact the overall
boot time.
In terms of reading files from the disk, Windows 7 has improvements in
the prefetching logic and mechanisms. Prefetching was introduced way
back in Windows XP. Since todays disks have differing performance
characteristics, the scheduling logic has undergone some changes to keep
pace and stay efficient.
As an example, we are evaluating the prefetcher on todays solid state
storage devices, going so far as to question if is required at all.
Ultimately, analysis and performance metrics captured on an individual
system will dynamically determine the extent to which we utilize the
prefetcher.
There are improved diagnostic experiences in Windows 7 as well. We aim to
quickly identify specific issues on individual systems, and provide help
to assist in resolving the issues. We believe this is an appropriate way
to inform users about some problems, such as having too many startup
applications or the presence of lengthy domain-oriented logon scripts.
As many users know, having too many startup applications is often the
cause of long boot times. Few users, however, are familiar with
implications of having problematic boot or logon scripts.
In Windows XP, Vista and in Windows 7, the default behavior for Windows is
to log the user into the desktop without waiting for potentially lengthy
networking initialization or scripts to run.
In corporate environments, however, it is possible for IT organizations to
change the default and configure client systems to contact servers across
the network. Unfortunately, when configuring clients to run scripts,
domain administrators typically do so in a synchronous and blocking
fashion. As a result, boot and logon can take minutes if networking
timeouts or server authentication issues exist. Additionally, those
scripts can run very expensive programs that consume CPU, disk and memory
resources.
In addition to working on Windows 7 specific features and services, we are
sharing tools, tests and data with our partners. The tools are available
to enthusiasts as well.
The tools we use internally to detect and correct boot issues are freely
available today here http://msdn.microsoft.com/en-us/library/cc305187.aspx
as a part of the Windows Performance Toolkit. While not appropriate for
most users, the tools are proving to be very helpful for some.
One of the topics we want to talk about in the future which we know has
been written about a great deal and is the subject of many comments, is
the role that additional software beyond the initial Windows installation
plays in overall system performance.
The sheer breadth and depth of software for Windows means that some
software will not have the high quality one would hope, while the vast
majority is quite good.
Microsoft must continue to provide the tools for developers to write high
performance software and the tools for end-users to identify the software
on their system that might contribute to performance that isnt meeting
expectations. Windows itself must also continue to improve the defensive
tactics it uses to isolate and inform the end-user about software that
might contribute to poor performance.
Another potential future topic pertains to configuration changes a user
can make on their own system. Many recommended changes arent helpful at
all.
For instance, weve found the vast majority of registry tweak
recommendations to be bogus.
Heres one of my favorites. If you perform a Live search for Enable
Superfetch on XP, youll get a large set of results. I can assure you, on
Windows XP there is no Superfetch functionality and no value in setting
the registry key noted on these sites.
As with that myth, there are many recommendations pertaining to CPU
scheduling, memory management and other configuration changes that arent
helpful to system performance.
Startup is one topic on performance. As described in the previous post we
want to continue the discussion around this topic. What are some of the
elements youd like to discuss more?
Michael Fortin
Ed. Note: This is our first post from a senior member of the development
team. Allow me to introduce Michael Fortin who is one of Microsofts
Distinguished Engineers and leads the Fundamentals feature team that is in
our Core Operating System group. Michael leads performance and reliability
efforts across the Windows platform. -- Steven (PS: Be sure to visit
www.microsoft.com/ie & try out the beta 2 release of Internet Explorer 8).
Posted by e7blog | 126 Comments
--
Cheers people
Stephen Loosley
Victoria Australia
------------------------------
Message: 2
Date: Fri, 5 Sep 2008 08:55:59 +1000
From: Russell Quinn <QN at boxhillhs.vic.edu.au>
Subject: [Year 12 SofDev] Upgrade from VB6 to VB.Net
To: "sofdev at edulists.com.au" <sofdev at edulists.com.au>
Message-ID: <5B8F0F74-8923-41D1-B181-41F97D68700A at mimectl>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
we are considering the move from VB6 to
VB.Net I have installed my personal version
of VB.Net onto a box connected to the intranet
for testing and we are constantly running into massages
about project not fully trusted. As usual Goggle
provides info about the solution but I note there are
a range of solutions including caspol.exe, Netrun,
Zone Stripper etc. Does anyone wish to nominate
the optimal solution to this problem?
Russell Quinn
Mailto: qn at boxhillhs.vic.edu.au
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.edulists.com.au/pipermail/sofdev/attachments/20080905/e6b74435/attachment-0001.html
------------------------------
Message: 3
Date: Fri, 05 Sep 2008 09:19:51 +1000
From: Kevin Feely <feely.kevin.k at edumail.vic.gov.au>
Subject: Re: [Year 12 SofDev] Upgrade from VB6 to VB.Net
To: "Year 12 Software Development Teachers' Mailing List"
<sofdev at edulists.com.au>
Message-ID: <48C06D17.2040306 at edumail.vic.gov.au>
Content-Type: text/plain; charset="iso-8859-1"
Hi Russell,
Each workstation needs to do this step - attached
regards
Kev
Russell Quinn wrote:
> Hi,
> we are considering the move from VB6 to
> VB.Net I have installed my personal version
> of VB.Net onto a box connected to the intranet
> for testing and we are constantly running into massages
> about project not fully trusted. As usual Goggle
> provides info about the solution but I note there are
> a range of solutions including caspol.exe, Netrun,
> Zone Stripper etc. Does anyone wish to nominate
> the optimal solution to this problem?
>
> Russell Quinn
>
> Mailto: qn at boxhillhs.vic.edu.au <mailto:qn at boxhillhs.vic.edu.au>
> _______________________________________________
> http://www.edulists.com.au <http://www.edulists.com.au> IT Software
> Development Mailing List kindly supported by
> http://www.vitta.org.au/vce/studies/infotech/softwaredevel3-4.html
> <http://www.vitta.org.au/vce/studies/infotech/softwaredevel3-4.html%20%20>
> - Victorian Curriculum and Assessment Authority and
> http://www.vitta.org.au <http://www.vitta.org.au> - VITTA Victorian
> Information Technology Teachers Association Inc
>
> __________ Information from ESET Smart Security, version of virus
> signature database 3416 (20080904) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com
Important - This email and any attachments may be confidential. If received in error, please contact us and delete all copies. Before opening or using attachments check them for viruses and defects. Regardless of any loss, damage or consequence, whether caused by the negligence of the sender or not, resulting directly or indirectly from the use of any attached files our liability is limited to resupplying any affected attachments. Any representations or opinions expressed are those of the individual sender, and not necessarily those of the Department of Education and Early Childhood Development.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Setting Security Level for Local IntraNet - Please do this
for VB.NET.doc
Type: application/msword
Size: 252928 bytes
Desc: not available
Url : http://www.edulists.com.au/pipermail/sofdev/attachments/20080905/e542d212/SettingSecurityLevelforLocalIntraNet-PleasedothisforVB.NET.doc
------------------------------
_______________________________________________
sofdev mailing list
sofdev at edulists.com.au
http://www.edulists.com.au/mailman/listinfo/sofdev
End of sofdev Digest, Vol 43, Issue 6
*************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.edulists.com.au/pipermail/sofdev/attachments/20080905/e02f657a/attachment-0001.html
More information about the sofdev
mailing list