<HTML dir=ltr><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText81902 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Thanks &nbsp;<FONT size=2>Kev,</FONT></FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>I will get the technician to try it.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>much obliged,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV></DIV>
<DIV id=idSignature61512>
<DIV><FONT face=Arial color=#000000 size=2>Russell Quinn</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>Mailto: <A href="mailto:qn@boxhillhs.vic.edu.au" target=_blank>qn@boxhillhs.vic.edu.au</A></FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> sofdev-request@edulists.com.au<BR><B>Sent:</B> Fri 5/09/2008 9:27 AM<BR><B>To:</B> sofdev@edulists.com.au<BR><B>Subject:</B> sofdev Digest, Vol 43, Issue 6<BR></FONT><BR></DIV>
<DIV><PRE style="WORD-WRAP: break-word">Send sofdev mailing list submissions to
        sofdev@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@edulists.com.au

You can reach the person managing the list at
        sofdev-owner@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@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@melbpc.org.au
Subject: [Year 12 SofDev] MS blog engineering Windows v7
To: link@anu.edu.au
Cc: sofdev@edulists.com.au, offtopic@edulists.com.au
Message-ID: &lt;20080904103754.317066E3@eagle.melbpc.org.au&gt;

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


&gt;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 &amp; 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 &lt;QN@boxhillhs.vic.edu.au&gt;
Subject: [Year 12 SofDev] Upgrade from VB6 to VB.Net
To: "sofdev@edulists.com.au" &lt;sofdev@edulists.com.au&gt;
Message-ID: &lt;5B8F0F74-8923-41D1-B181-41F97D68700A@mimectl&gt;
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@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 &lt;feely.kevin.k@edumail.vic.gov.au&gt;
Subject: Re: [Year 12 SofDev] Upgrade from VB6 to VB.Net
To: "Year 12 Software Development Teachers' Mailing List"
        &lt;sofdev@edulists.com.au&gt;
Message-ID: &lt;48C06D17.2040306@edumail.vic.gov.au&gt;
Content-Type: text/plain; charset="iso-8859-1"

Hi Russell,
Each workstation needs to do this step - attached
regards
Kev

Russell Quinn wrote:
&gt; Hi,
&gt;     we are considering the move from VB6 to
&gt; VB.Net  I have installed my personal version
&gt; of VB.Net onto a box connected to the intranet
&gt; for testing and we are constantly running into massages
&gt; about project not fully trusted.  As usual Goggle
&gt; provides info about the solution but I note there are
&gt; a range of solutions including caspol.exe, Netrun,
&gt; Zone Stripper etc.  Does anyone wish to nominate
&gt; the optimal solution to this problem?
&gt;  
&gt; Russell Quinn
&gt;  
&gt; Mailto: qn@boxhillhs.vic.edu.au &lt;mailto:qn@boxhillhs.vic.edu.au&gt;
&gt; _______________________________________________
&gt; http://www.edulists.com.au &lt;http://www.edulists.com.au&gt; IT Software 
&gt; Development Mailing List kindly supported by
&gt; http://www.vitta.org.au/vce/studies/infotech/softwaredevel3-4.html 
&gt; &lt;http://www.vitta.org.au/vce/studies/infotech/softwaredevel3-4.html%20%20&gt; 
&gt; - Victorian Curriculum and Assessment Authority and
&gt; http://www.vitta.org.au &lt;http://www.vitta.org.au&gt; - VITTA Victorian 
&gt; Information Technology Teachers Association Inc
&gt;
&gt; __________ Information from ESET Smart Security, version of virus 
&gt; signature database 3416 (20080904) __________
&gt;
&gt; The message was checked by ESET Smart Security.
&gt;
&gt; 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@edulists.com.au
http://www.edulists.com.au/mailman/listinfo/sofdev


End of sofdev Digest, Vol 43, Issue 6
*************************************
</PRE></DIV></BODY></HTML>