Posts Tagged ‘Windows 7’

I was under the impression that module manifests allow only DATA stuff. In fact, if you try to use cmdlets or variables in them, you get the usual Data-language errors, like this:

Import-Module : The module manifest ‘C:\Modules\Test\Test.psd1’ could not be processed because it is not a valid PowerShell restricted language file. Please remove the elements that are not permitted by the restricted language: The command ‘Get-ChildItem’ is not in allowed in restricted language mode or a Data section.

Import-Module : The module manifest ‘C:\Modules\Test\Test.psd1’ could not be processed because it is not a valid PowerShell restricted language file. Please remove the elements that are not permitted by the restricted language: A variable that cannot be referenced in restricted language mode or a Data section is being referenced. Variables that can be referenced include the following: $PSCulture, $PSUICulture, $true, $false, and $null.

BUT THEN I came across this in the Windows 7 built-in BitsTransfer module:

RequiredAssemblies=Join-Path $psScriptRoot “Microsoft.BackgroundIntelligentTransfer.Management.Interop.dll”

AND IT WORKS?!

Well, that’s very weird, because Join-Path is certainly not allowed in a normal “restricted language” file, and (as you can tell from above) neither is $PsScriptRoot — in fact, as far as I know, you shouldn’t have to do that at all, since RequiredAssemblies knows enough to look in your module folder… but nevermind that, why does it work?

The Rest of the Story

So I went digging, and it turns out that although they are parsed as Restricted Language (like a “data section,” see about_Data_Sections), module manifests are allowed extra cmdlets: “Import-LocalizedData”, “ConvertFrom-StringData”, “Write-Host”, “Out-Host”, “Join-Path” and even special variables that aren’t normally allowed in data sections: specifically $PsScriptRoot which is the ModuleBase (the parent folder of the psd1) and environment variables ($Env:), plus the usual $PSCulture, $PSUICulture, and of course $true, $false, and $null.

However, although you can use those variables, you can’t embed them in strings, so if you wanted to use $Env:Windir or $Env:Temp as part of a path (for instance), you need to take advantage of the availability of Join-Path.

Now, I can’t find this documented anywhere (although I did add it to the module manifest documentation on MSDN), but it’s true, nonetheless — you’ll just have to trust me Yeah, PowerShell is starting to drive me crazy again.

Related articles by Zemanta

• A question about PowerShell Module Manifests (huddledmasses.org)
• Another Module Manifest Gotcha (huddledmasses.org)

Microsoft has been very busy this year … and in these last couple of months before the general availability of Windows 7, they’re trying very hard to crank out the tools necessary to encourage development of Windows 7 applications.

The first tool out of the gate, of course, was the Windows API Code Pack for the .Net framework. A nice library that makes it simple to write applications that take advantage of new Windows Vista and Windows 7 features like Libraries, Task panes and jump lists. Of course, that library has a major problem: it’s got an ugly and confusing license. Rather than using one of the standard Microsoft Open Source Licenses, the team used a license from the dark ages that features the vague “Excluded Licenses” clause and other ugly terminology.

More recently, Microsoft has announced a Platform Update for Vista which is intended to allow Vista to run most applications designed for Windows 7. The Platform Update is a set of runtime libraries which includes the Windows Ribbon control; Automation Manager Library; DirectX updates for hardware acceleration; DirectCompute for hardware-accelerated parallel computing support; the XPS printing library; the Windows Automation API; and the Windows Portable Devices Platform, which standardizes data transfers across apps and portable devices. This important package will be made available through Windows Update (and applications will be able to prompt you to download it) and it is in public beta with more information on the Windows Team blog. A couple of pieces of that will be made available for Windows XP; particularly the Automation API, which allows accessibility tools and test automation tools to access Windows user interface in a consistent way — this will mean that the next release of WASP will work flawlessly across Windows XP, Vista, and Windows 7.

Also in the works is the Remote Desktop Connection 7.0 (RDC7) client for Windows XP and Windows Vista to allow these older clients to take advantage of all new server features in Windows 7 and Windows Server 2008, including multi-monitor support and media redirection. There’s more information about that on the Remote Desktop team blog.

And finally, the release candidate for the Windows Management Framework (WMF) is also available. The WMF will include WinRM (Microsoft’s implementation of the WS-Management spec), PowerShell 2.0, and BITS for Server 2008, Windows Vista, Server 2003, and of course, Windows XP. This means that if you’re on Vista, or still using Windows XP, you can now upgrade from the PowerShell 2.0 CTP 3 to this release candidate and expect remoting to work!

All of these should be seeing final releases in the very near future, and some of them possibly by the time Windows 7 is released to the public.

Related articles by Zemanta

• Make a bootable USB installer for Windows XP, Vista, 7 with WinToFlash (downloadsquad.com)
• Microsoft, Intel build fast, efficient Windows 7 machines (infoworld.com)
• Free Windows 7 Upgrade (techblissonline.com)
• Users abandon XP for Vista, Windows 7 (infoworld.com)
• Fun with PInvoke and Aero Peek (huddledmasses.org)
• Microsoft: Windows 7 not affected by latest flaw (news.cnet.com)

I gave a presentation at the upstate New York PowerShell user group last night about the new stuff in PowerShell 2 — giving it really made me think about how I’m just so used to PowerShell 2 that I’ve forgotten about how much of it is new in this version — and how cool each of these new things are. In fact, in my list of 7 areas that I talked about, I bet we could find a PowerShell MVP for at least each of the top 6 that would be willing to argue for that one being the most important new feature in PowerShell 2

Having said that, below is the text from my slides … my personal “highlights” of what’s new in PowerShell 2.

What’s New In PowerShell 2?

Advanced Functions

Modules

Help

Remoting

Eventing

Integrated Script Editor (debugging)

Transaction support

… and more

Advanced Functions

• Parameter parsing & binding

  • Mandatory
  • Position
  • ValueFromPipeline
  • ValueFromPipelineByPropertyName
  • ValueFromRemainingArguments

• Parameter validation

  • IsNull
  • IsNotNull
  • Set
  • Range
  • Count
  • RegEx Pattern
  • Script

• Parameter Sets

• CmdletBinding Support

  • SupportsShouldProcess
  • ConfirmImpact
  • DefaultParameterSetName

• Dynamic parameters

Modules

• XCopy deploy (PSModulePath)

• Module manifests use .psd1 extension

• Script Modules use .psm1 extension

  • Organization

  • Private variables and functions

• Import modules easily, (and remove)

• Related Cmdlets:

  • Get-Module
  • New-Module
  • Import-Module
  • Remove-Module
  • Export-ModuleMember

Help for Functions and Scripts

• XML-based help   (just like cmdlets)

• Comment-based help

• Online help

• Provider-based help additions

• Get-Help now searches!

  • e.g.: man hashtable

Comment-Based Help Example

<#
.SYNOPSIS
A short description of the function.

.DESCRIPTION
A longer description of the function.

.PARAMETER <parametername>
The documentation for that specific parameter

.EXAMPLE
C:\PS> some example code

.LINK
Get-AnotherFunction

.LINK
http://yourwebsite.com/help/documentation
#>

Comment-Based Help Keywords

• Synopsis
• Description
• Parameter
• Example
• Inputs
• Outputs
• Notes
• Component
• Role
• Functionality
• ForwardHelpTargetName
• ForwardHelpCategory
• RemoteHelpRunspace
• Link
• ExternalHelp

Remoting

• Fan-in and Fan-out remoting

• Requires PowerShell 2.0 on both ends

• Receive serialized property bags, not live objects

• WinRM = WS-Management = SOAP spec

• Enable-PSRemoting requires elevation

• Related Cmdlets:

  • New-PsSession

  • Get-PsSession

  • Remove-PsSession

  • Export-PsSession

  • Import-PsSession

  • Enter-PsSession

  • Exit-PsSession

  • Invoke-Command

Background Jobs

• Execute work asynchronously

• Separate runspace

• Related Cmdlets:

  • Start-Job
  • Stop-Job
  • Get-Job
  • Receive-Job
  • Wait-Job
  • Remove-Job
  • Invoke-Command

Eventing

Finally provides support for asynchronous Events, for GUIs, timers, WMI, and remoting

• Events can be forwarded from remote sessions

• Related Cmdlets:

  • Register-EngineEvent
  • Register-ObjectEvent
  • Register-WmiEvent
  • RegisterUnregister-Event
  • Get-EventSubscribers
  • New-Event
  • Get-Event
  • Wait-Event
  • Remove-Event

Integrated Script Editor – ISE

• Graphical host for PowerShell engine

• Tabbed script editor

• Supports Unicode!

• Supports script debugging (about_debuggers)

  • Graphical debugging like an IDE

  • Set breakpoints, stop conditions, etc

• Related Cmdlets:

  • Set-PSDebug
  • Set-StrictMode
  • Get-PSCallStack
  • Get-PSBreakpoint
  • Set-PSBreakpoint
  • Remove-PSBreakpoint
  • Enable-PSBreakpoint
  • Disable-PSBreakpoint

Transaction Support

• Commit/rollback semantics

• Rollback can be automatic (if error occurs)

• Registry provider is only supporter in the box

• Related Cmdlets:

  • Start-Transaction
  • Complete-Transaction
  • Undo-Transaction
  • Get-Transaction
  • Use-Transaction

107 New Cmdlets

• Add-Computer
• Add-Type
• Checkpoint-Computer
• Clear-EventLog
• Clear-History
• Complete-Transaction
• Connect-WSMan
• ConvertFrom-Csv
• ConvertFrom-StringData
• ConvertTo-Csv
• ConvertTo-Xml
• Debug-Process
• Disable-ComputerRestore
• Disable-PSBreakpoint
• Disable-PSSessionConfiguration
• Disable-WSManCredSSP
• Disconnect-WSMan
• Enable-ComputerRestore
• Enable-PSBreakpoint
• Enable-PSRemoting
• Enable-PSSessionConfiguration
• Enable-WSManCredSSP
• Enter-PSSession
• Exit-PSSession
• Export-Counter
• Export-FormatData
• Export-ModuleMember
• Export-PSSession
• Get-ComputerRestorePoint
• Get-Counter
• Get-Event
• Get-EventSubscriber
• Get-FormatData
• Get-HotFix
• Get-Job
• Get-Module
• Get-PSBreakpoint
• Get-PSCallStack
• Get-PSSession
• Get-PSSessionConfiguration
• Get-Random
• Get-Transaction
• Get-WinEvent
• Get-WSManCredSSP
• Get-WSManInstance
• Import-Counter
• Import-LocalizedData
• Import-Module
• Import-PSSession
• Invoke-Command
• Invoke-WmiMethod
• Invoke-WSManAction
• Limit-EventLog
• New-Event
• New-EventLog
• New-Module
• New-ModuleManifest
• New-PSSession
• New-PSSessionOption
• New-WebServiceProxy
• New-WSManInstance
• New-WSManSessionOption
• Out-GridView
• Receive-Job
• Register-EngineEvent
• Register-ObjectEvent
• Register-PSSessionConfiguration
• Register-WmiEvent
• Remove-Computer
• Remove-Event
• Remove-EventLog
• Remove-Job
• Remove-Module
• Remove-PSBreakpoint
• Remove-PSSession
• Remove-WmiObject
• Remove-WSManInstance
• Reset-ComputerMachinePassword
• Restart-Computer
• Restore-Computer
• Select-Xml
• Send-MailMessage
• Set-PSBreakpoint
• Set-PSSessionConfiguration
• Set-StrictMode
• Set-WmiInstance
• Set-WSManInstance
• Set-WSManQuickConfig
• Show-EventLog
• Start-Job
• Start-Process
• Start-Transaction
• Stop-Computer
• Stop-Job
• Test-ComputerSecureChannel
• Test-Connection
• Test-ModuleManifest
• Test-WSMan
• Undo-Transaction
• Unregister-Event
• Unregister-PSSessionConfiguration
• Update-List
• Use-Transaction
• Wait-Event
• Wait-Job
• Wait-Process
• Write-EventLog

Miscellaneous

• Try { } Catch{ } Finally { }

• Add-Type cmdlet – compiles .NET code

• Splatting: @

• Steppable pipelines for wrapping cmdlets

• -Split and –Join

• Script Internationalization

• Lots of cmdlet improvements

• Select-String … -NotMatch -AllMatches -Context 3

There are so many fun things you can do in Windows when your scripting language allows you to make PInvoke calls to Win32 APIs … but I have to say it’s amazing how many things have been added to Windows recently and still left out of the .Net framework …

Anyway, on to the Aero Peek stuff. If you haven’t seen it, Aero Peek is a feature of Windows 7, which lets you get a peek at your desktop, or at a single window for a moment. Basically, you can press Win+Space (the Windows logo key and the space bar) and all of your open windows instantly turn transparent, revealing … whatever was on your desktop: wallpaper, icons, and gadgets. You can also use it by hovering your mouse on the right corner of the taskbar, or you can peek at a single window by hovering over it’s taskbar button and then over it’s thumbnail.

In any case, I have a couple of windows which I would like to have stay visible on the desktop when I hit the aero peek hotkey: Rainlendar and Miranda. It turns out there’s a simple API call for this: DwmSetWindowAttribute which lets you set the DWMWA_EXCLUDED_FROM_PEEK attribute to ENABLED … causing a window to no longer hide when you press that hotkey. Of course, that API call should be made by those apps, in response to a user setting (so I’ve told their authors about it), but it doesn’t have to be (so I wrote a script to do it myself).

In the old days, I would have written a little systray app which would give you a popup list of all windows, or perhaps added a menu item to a window’s right-click menu … and I would have had to deal with creating some way to persist which apps you wanted to apply this to, and then I could have applied the setting to them whenever you opened them.

But now, I have PowerShell. I don’t need to give you menus and store settings, because I can just let you edit a little script instead.

So here’s a script which will let you turn off Aero Peek transparency for windows by window title and/or process name … Once you have this function available, you can keep Rainlendar’s calendar, tasks, and event windows all visible by just running Remove-AeroPeek -Process Rainlendar2 or you can keep your Miranda contact list visible by running Remove-AeroPeek "Miranda IM" (although you should not that depends on the window title matching just that one window — and Miranda lets you change what your title is, so you may have to adjust it).

Of course, that script really deserves explanation, because it’s showing off quite a few advanced things…

The first thing is that I’m using a Try/Catch block in the BEGIN block to make sure I only execute that code once. You can’t call Add-Type with the same code multiple times in a single PowerShell session, because the type will already exist when you call it the second time. So the code in the try block will throw an exception if the type doesn’t already exist, and in the catch handler, we’ll create the type, and define the other function we need.

Add-Type is a super-powerful cmdlet which compiles code on the fly (or imports types from pre-compiled assemblies). In this case we’re using it to import a little class called Dwm which I started writing myself from PInvoke.net and the MSDN documentation, but then eventually copied most of from a NeoWin forum thread… All this class really does is define the API function and the flags we need to pass to it, and then provides a wrapper for the DwmSetWindowAttribute call. We could have written that call in PowerShell, but at the end of the day, once you start compiling C# code in PowerShell, it’s hard to know when to stop

The Select-Window function is (yet another customized version of) a function I wrote awhile back on PoshCode as part of my (still in progress) rewrite of WASP to use the UIAutomationClient … I’ve just modified it to add only the three properties of the window that I’m interested in: Title and ProcessId (for identifying the correct windows) and Handle (for passing to the DwmSetWindowAttribute call). It uses the RootElement property of System.Windows.Automation.AutomationElement to do a search, and then a series of GetCurrentPropertyValue calls to determine the Name, ProcessId, and NativeWindowHandle of the windows it finds.

That’s pretty much all there is to it, other than filtering out the window(s) that we want and actually calling the API. I think I’m going to have to play a little bit more with this to see what else we can do — I’ve already realized that this means we can make little widgets with PowerBoots and set them to stick around just like regular desktop gadgets …

So, last year around April, I wrote this module I called “HuddledTricks” ... it has a function for hiding windows, and another for showing them, along with a function called Wiggle-Mouse which, well, wiggles your mouse cursor (and one called Steady-Mouse to stop it).

So anyway, today I was playing with something else and with my WASP module, and discovered that you can hide the Windows 7 taskbar without hiding the start menu or button.

This seemed cool enough to motivate me to finally actually publish my HuddledTricks module, so have fun, and don’t prank too many people.

So, I wrote up this great explanation about how much the Shell in Windows 7 has changed from Vista, and how this shows that this Windows 7 beta is a much bigger deal than most of the whiners in the press are giving it credit for being, and explain about how I used to be a shell developer, and how that means I should have credibility when it comes to discussing changes in the taskbar, systray, desktop, and their various preference panels ….

Then Windows 7 bluescreened

I think the drivers for Mesh, (maybe VirtualCloneDrive, or Eset’s NOD32) ... didn’t like going into hibernation. Anyway, I lost all that, so let me just list for you some of the changes just in the shell. I’m going to ignore the multi-touch capability, and “Homegroup“s, and the “Libraries” that are really impressive if you’ve never learned how to make a junction …

1. You have complete control over what icons show in the systray. By default, new apps don’t get to show you anything. Hurrah!
2. You can chose large icons for task bar. Actually, it defaults to large icons, so I guess I should say you can choose small icons, but since that’s all that was available in previous versions of Windows, it seems like the new stuff should be what I mentioned. Oh, you know what these larger icons mean?
1. The systray clock now shows the date by default (hurrah!). Ok, I know that’s not actually a big change, but it’s a tiny thing that makes me happier.
2. Each running process gets exactly ONE (squarish) tile on the task bar, with a little extra ridge on the side if it represents more than one window. Of course, that’s just the default:
3. You can switch the text labels back on to make things look like before
1. You can turn off the “grouping” so each window gets it’s own button
3. You can drag tasks on the taskbar to reorder them. I’ve been using Taskix as one of my first installs for years, so this isn’t as big a deal as it could be, but it’s pretty interesting, when you combine it with:
4. You can use WIN+ to launch another copy of a task (based on the order they’re in on the taskbar). Incidentally, if anyone from the team is listening, you should focus the already running task, if there is one, so that pressing Win+# is like clicking the button. Oh, and WIn+Shift+# could run a new one.
5. Mousing over a taskbar tile pops out a pane with thumbnails of each window (or tabs), and mousing over the thumbnails actually hides all the other windows so you can see just that window (or tab) ... and there’s even a close button, so you can close the ones you don’t want without switching to them
6. Dragging a window to a screen edge lets you tile it in place, or maximize it. Cool, and about time ... really we need a few other options on this too, and it should work on the “inside” edges of a multi-monitor setup (hopefully they’ll fix that).
7. The right-click menu for a task tile is customizable: it can show you a list of things to chose from to open in that app: like your recent folders (file manager), your recent history (browser), your “status” (instant messenger), etc.
8. There’s (almost always) a button on that right-click menu for launching another copy of the app. And you can right-click it to get the “run as admin”
9. The task bar tiles can show (become, really) a progress bar! I can’t explain how cool this is, or how many other things it could be used for, but if you’ve got Windows 7, try downloading something large in IE8 — you actually see the progress as a green background on the taskbar button. I have to investigate whether this means you can owner-draw stuff on the taskbar, or if they’ve just provided progress bars built-in. If it’s the former, you can expect to see lots of cool stuff in the near future (like counts of unread messages or emails, etc).
10. Two tiles for the same app appear to be merged together — That is, if you unstack windows, or choose to stack only when there are too many to fit, the borders between buttons are less visible, and the mouse-over highlight carries across them. This is most noticeable if you make your taskbar vertical.

1. There is coloring of apps, so when you mouse over the taskbar buttons, they get highlighted in a color that is based on their icon.

OK, there’s actually more changes than just those … the desktop wallpaper has a built-in “slideshow” feature, so you can have your wallpaper change every day (or every 10 seconds, or something in between). The UAC prompts have a link on them to the UAC preference panel where you can disable UAC as easy as sliding a slider. The taskbar can “learn” just like the start menu does, to keep the apps you use the most always available… or you can just pin those apps to the taskbar manually (again, just like the start menu).

So there’s lots of cool new features in the shell, even without getting into touch interfaces and other stuff, and generally, I think this represents a bigger change than the windows 95-98 and possibly even bigger than 2000 to XP, and on top of all that, the relative performance of the system seems to go in the right direction for a change.