I experimented with a powershell script  in the start folder. I had some issues. I am still not sure how to get consecuitive commands that share the same environment running.  So I simply appended my function name after defining it in my script.  I did not use the "-file" option but invoked the script like a command from a cmd.exe file.  This cmd.exe file still requires me to type an Administrative password after startup. Not quite sure how to get around that... 

:: Powershell startup to pump established connections to the Event Log 

:: see http://www.rmfdevelopment.com/PowerShell_Scripts/List-TCPConnections_Advanced.ps1

echo Powershell -windowStyle hidden -noexit -noprofile "& D:\PS1\netstat_Established_log_startup.ps1" >TCPListen.cmd

runas /profile /env /user:Administrator TCPListen.cmd

Metadata

Jason Shirk's excellent post on meta-programming inspired this function and alias I have added to my profile to help me get a handle on the use and format of paramaters in CTP2 v3 scripts. 

function Create-Metadata($args0) {

$args0 = new-object System.Management.Automation.CommandMetadata (get-command $args0)

[System.Management.Automation.ProxyCommand]::Create($args0) | out-file ProxyCommand.txt

more ProxyCommand.txt

}

Set-Alias cm Create-Metadata

Run as below:

CM("trace-command")

[CmdletBinding(DefaultParameterSetName='expressionSet')]

param(

    [Parameter(ValueFromPipeline=$true)]

    [System.Management.Automation.PSObject]

    ${InputObject},

    [Parameter(Mandatory=$true, Position=0)]

    [System.String[]]

    ${Name},

    [Parameter(Position=2)]

    [System.Management.Automation.PSTraceSourceOptions]

    ${Option},

    [Parameter(ParameterSetName='expressionSet', Mandatory=$true, Position=1)]

    [System.Management.Automation.ScriptBlock]

    ${Expression},

    [Parameter(ParameterSetName='commandSet', Mandatory=$true, Position=1)]

    [System.String]

    ${Command},

    [Parameter(ParameterSetName='commandSet', ValueFromRemainingArguments=$true)]

    [Alias('Args')]

    [System.Object[]]

    ${ArgumentList},

    [System.Diagnostics.TraceOptions]

    ${ListenerOption},

    [Alias('PSPath')]

    [System.String]

    ${FilePath},

  .....

Some notes on FileVersionInfo, finding Modules, loaded dlls:

(get-process -id $pid).modules | %{$_} | fl * | more

Size              : 152

Company           : Microsoft Corporation

FileVersion       : 6.1.6949.0 (fbl_srv_powershell_ctp(srvbld).081105-1651)

ProductVersion    : 6.1.6949.0

Description       : Windows PowerShell

Product           : Microsoft? Windows? Operating System

ModuleName        : PowerShell.exe

FileName          : C:\WINDOWS\system32\WindowsPowerShell\v1.0\PowerShell.exe

BaseAddress       : 579928064

ModuleMemorySize  : 155648

EntryPointAddress : 579954429

FileVersionInfo   : File:             C:\WINDOWS\system32\WindowsPowerShell\v1.0\PowerShell.exe

                    InternalName:     POWERSHELL

                    OriginalFilename: PowerShell.EXE

                    FileVersion:      6.1.6949.0 (fbl_srv_powershell_ctp(srvbld).081105-1651)

                    FileDescription:  Windows PowerShell

                    Product:          Microsoft? Windows? Operating System

                    ProductVersion:   6.1.6949.0

                    Debug:            False

                    Patched:          False

                    PreRelease:       False

                    PrivateBuild:     True

                    SpecialBuild:     False

                    Language:         English (United States)

....

A workable tlist substitute:

$a =foreach ($id in (get-process)) {write $id.Name,$id.Size,$id.modules}

$a | more

alg

   Size(K) ModuleName                                         FileName

   ------- ----------                                         --------

        52 alg.exe                                            C:\WINDOWS\System32\alg.exe

       700 ntdll.dll                                          C:\WINDOWS\system32\ntdll.dll

       984 kernel32.dll                                       C:\WINDOWS\system32\kernel32.dll

       352 msvcrt.dll                                         C:\WINDOWS\system32\msvcrt.dll

        68 ATL.DLL                                            C:\WINDOWS\System32\ATL.DLL

       580 USER32.dll                                         C:\WINDOWS\system32\USER32.dll

       292 GDI32.dll                                          C:\WINDOWS\system32\GDI32.dll

       620 ADVAPI32.dll                                       C:\WINDOWS\system32\ADVAPI32.dll

       584 RPCRT4.dll                                         C:\WINDOWS\system32\RPCRT4.dll

        68 Secur32.dll                                        C:\WINDOWS\system32\Secur32.dll

      1268 ole32.dll                                          C:\WINDOWS\system32\ole32.dll

       556 OLEAUT32.dll                                       C:\WINDOWS\system32\OLEAUT32.dll

        36 WSOCK32.dll                                        C:\WINDOWS\System32\WSOCK32.dll

.....

This will be worth some more investigation.  I can send a Powershell array of cmd.exe strings to the cmd.exe interpreter and pass cmd.exe a Powershell "here string" that will passthru a Powershell variable to the cmd.exe interpreter. Be interesting to next see if I can reverse the process.

# writes out time and date from cmd.exe

write "Time and Date from CMD.EXE:" 

$Global:command = 

"time /t",

"date /t"

out-file -inputobject $command -encoding ASCII -filepath $pwd\cmd.txt

Start-Process cmd.exe -argument /Q -nonewwindow -wait -redirectstandardinput $pwd\cmd.txt

Finding Time

FindingTimes in Powershell (and cmd.exe).  I have put the script FindingTimes.ps1 in my repository.  I am returning various results.  This script demonstrates different methods of finding System Time and Uptime on Windows with cmd.exe or Powershell.  There is a discrepancy in the method results between .NET and GWMI. I do not know what is causing this, I suspect the hibernate process or uptime.exe heartbeat function (from MS Reskit) is causing the descrepancy.

PS D:\PS1> .\FindingTime_001.ps1

Finding Current and Boot Times from Powershell: A Medley of Methods

System Times:

Time now using Get-Date:

03/16/2009 19:41:35

DisplayHint : DateTime

DateTime    : Monday, March 16, 2009 7:41:35 PM

Date        : 3/16/2009 12:00:00 AM

Day         : 16

DayOfWeek   : Monday

DayOfYear   : 75

Hour        : 19

Kind        : Local

Millisecond : 343

Minute      : 41

Month       : 3

Second      : 35

Ticks       : 633728292953437500

TimeOfDay   : 19:41:35.3437500

Year        : 2009

Time From .NET:

.NET Date Time Now is 03/16/2009 19:41:35

.NET UTC Date Time Now is 03/17/2009 02:41:35

.NET Time is Date Hours Minutes Seconds MS : 16 19 41 35 359

.NET UTC Time is Date Hours Minutes Seconds MS : 17 2 41 35 359

.

Time from WMI Win32_OperatingSystem LocalDateTime:

03/16/2009 19:41:35

.

Time and Date from CMD.EXE:

Microsoft Windows XP [Version 5.1.2600]

(C) Copyright 1985-2001 Microsoft Corp.

D:\PS1>07:41 PM

D:\PS1>Mon 03/16/2009

D:\PS1>.

System UpTimes:

Uptime for cmd.exe

Microsoft Windows XP [Version 5.1.2600]

(C) Copyright 1985-2001 Microsoft Corp.

D:\PS1>Running cmd.exe

D:\PS1>Current TimeStamp is 03.16.2009_19.41.35.59

Statistics since 3/14/2009 9:45 AM

.

Uptime From Microsoft Resource Kit: 'D:\uptime.exe:'

\\RMFMEDIA has been up for: 2 day(s), 9 hour(s), 57 minute(s), 26 second(s)

.

Uptimes from the System Event 6009 Log Query and (get-date): Elapsed from Last Boot Times

Last boot Date/Time -- LBTs from Current Time in Days.Hours.Minutes.Seconds

03/14/2009 09:44:52 -- 2.9.56.44

03/04/2009 14:25:00 -- 12.5.16.36

02/20/2009 01:24:35 -- 24.18.17.1

02/19/2009 20:47:39 -- 24.22.53.57

02/18/2009 11:10:45 -- 26.8.30.51

02/16/2009 10:24:21 -- 28.9.17.15

02/16/2009 10:10:47 -- 28.9.30.49

02/03/2009 11:33:24 -- 41.8.8.12

01/15/2009 22:40:17 -- 59.21.1.19

01/09/2009 09:52:51 -- 66.9.48.45

01/07/2009 17:39:39 -- 68.2.1.57

01/05/2009 18:30:06 -- 70.1.11.30

01/05/2009 11:01:59 -- 70.8.39.37

12/24/2008 11:20:21 -- 82.8.21.15

.

Uptime from Get-WmiObject -class Win32_PerfFormattedData_PerfOS_System

Number of Days = 2.41489583333333

Number of Hours = 57.9575

Number of Minutes = 3477.45

Number of Seconds 208647

.

Uptme from GWMI Win32_OperatingSystem -Namespace root\CIMV2 LastBootUpTime and (get-date)

Last Boot Time: 03/16/2009 03:33:43 Current Time: 03/16/2009 19:41:36

Uptimes from Last Boot in Days.Hours.Minutes.Seconds = 0.16.7.52

.

Uptime from Get-WmiObject -class Win32_OperatingSystem LastBootUpTime and LocalDateTime

Uptime is 0.16.7.52

.

Uptime from D:\cygwin\bin\uptime.exe (procps version 3.2.6)

 19:41:36 up 16:07,  1 user,  load average: 0.00, 0.00, 0.00

.

The last few days have been horrible for me.  There is a level of knowledge I am missing about .NET and Powershell that is preventing me from doing great new creative things. Fortunately, there are brilliant coders like Josh Einstein and others stumbling across similar issues. For example:http://groups.google.com/group/microsoft.public.windows.powershell/browse_thread/thread/40356985a4e3e015/9112f551260968f0?hl=en#9112f551260968f0

It's amazing how useful ad-hoc discussions about new features in CTPv3 are to many us. "Jaykul"Bennett posted one I am sure is being mined from all over the world:

http://huddledmasses.org/a-guide-to-advanced-functions/#more-1116

Oh well, back to Holmes, Payette, Deshev, and others and see if I can figure out what I am doing. Perhaps some time spent just reading .NET  and C# books would be useful....hmmmm...

I've posted this:

"In learning Powershell, once you are over the humps of the pipeline, 
automatic variables, conditional loops, .NET, network admin tricks 
etc. (e.g. a "better cmd line"),  you are faced with absorbing the 
intent of the architects in creating and using functionality like: 

params for Functions 
scriptlets 
[cmdletbinding] 
Cmdlet architecture 

etc. and a subset of other dev skillsets like error handling, 
debugging that would make the difference for between someone who is 
rewriting his 10 line cmd scripts or someone who is creating 
significant functionality in Powershell scripts.  I think what I would 
like is book with a title like "Design Patterns for Powershell" that 
provides examples and discussion on how to best implement Powershell 
for performance, for re-usable design, when something more "lambda" 
than "imperative" makes sense and the converse.  Currently, there is a 
lot of research leg work to go through to come up with this "all by 
your lonesome".  Other pieces of this might be a Visio or VisStudio 
design template(s), advice on writing testable and easily debugged 
functions, PSIE extensions that provide for intellisense or design 
templates. It's true folks like Bennet, Lee, Snover, Payette, Holmes, 
and the Powershell team have some discussion and some examples  about 
this...but I find myself with many questions...and feeling a little 
confused.  Do I need to master "Design Patterns for C#" or understand 
Functional Language style vs. Imperative Language issues before I 
write elegant, correct, re-usable functions, and scriplets for 
Powershell?"