RSS Feed 
- The Quick Launch Toolbar in Windows XP and in Vista seems a very good idea that you might miss when using Windows 7. Fortunately though, you can get it back in a quick few steps. Right click the taskbar, go to Toolbar -> New Toolbar and type “%UserProfile%\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch” into the folder box, then click Select Folder. To make it look like it would in Windows Vista, right click the taskbar, uncheck “Lock the Taskbar”, then right click the divider and uncheck “Show Title” and “Show Text”. Then right click the taskbar and check “Show Small Icons” and you should be done.
our poll
বুধবার, ২৬ আগস্ট, ২০০৯
Activate The Quick Launch Toolbar
Multi-threaded File Copy
- If you are a more advanced user, you’ve heard already about Robocopy. Now it’s included in Windows 7 and lets you perform multi-threaded copies from the command line. You can choose the number of threads like this “/MT[:n], which can be from 1 to 128.
Combine Taskbar Icons
- When you have more windows or applications opened, the taskbar’s space might not be enough for them all, so you need to combine them, just like you would in Windows XP or Vista. To do this, right-click the Start button, then go to Properties -> Taskbar and check “Combine when taskbar is full”.
Background Photo Slideshow
- If you are like me, lazy and bored, then you will want to change the background from time to time, wasting a lot of time. Now you don’t have to do this anymore, because you can set up a slideshow. Right click on the desktop then go to Personalize -> Desktop Background and hold the CTRL key while choosing the images. Then you can choose the time intervals between images and opt to display them randomly or in a row.
Make The Taskbar Smaller
- If you feel like the taskbar is using too much of your screen space, you can choose to make the icons smaller. To do this, right-click on the Start button, then go to Properties -> Taskbar and set it to “Use small icons”
Dock The Current Windows To The Right Side Of The Screen
- Press the Windows key + Right key to dock it to the right side of the screen.
Dock The Current Windows To The Left Side Of The Screen
- This new feature seems useful because sometimes it’s disturbing that windows seems to float like crazy on the screen and it’s hard to attach them to one side of it. Now this can easily be done using a keyboard shortcut. Press the Windows key + Left key to dock it to the left side of the screen.
Display Empty Removable Drives
- Windows 7 will not show empty drives by default, so if you connect an empty drive to your PC, don’t worry, just go to Tools -> Folder Options -> View and uncheck “Hide empty drives in the computer folder”. This doesn’t seem like a good idea and it should not be default setting, because it will be hard for inexperienced users to figure it out. I bet a lot of users will return their newly bought drive thinking it’s broken.
Burn Images
- We all had trouble with image burning in Windows, because it couldn’t do it itself, a standalone software being needed. With Windows 7 this will not be a problem anymore. All you have to do is double-click the ISO image and burn it on the CD or DVD that’s inserted in the drive.
AppLocker
- If you are usually sharing your computer with someone else, then you might want to restrict their access to your applications, files or documents. Using the AppLocker tool, you have a few options to do this by blocking other users to access Executables, Windows Installers, Scripts, a specific publisher or path. You can simply do this by pressing the Windows key then typing Gpedit.msc. Then go to Computer Navigation -> Windows Settings -> Security Settings -> Application Control Policies -> AppLocker. Right click on one of the options ( Executables, Installers, or Script ) and create a new rule. That should save you from a lot of headaches.
মঙ্গলবার, ২৫ আগস্ট, ২০০৯
Windows 7 is doing quite good these days. After Microsoft launched the Betarelease that is available for everyone to download. And many people who are lucky enough to use the new Windows 7 beta say that it is cool, fast, and nice looking! Well, I must say that I totally agree. I am using it and I haven’t had any problems with it… It works like a charm…
But if you have some crap pc ( don’t worry, I know it’s only temporarily) or maybe some other obstacles that don’t let you install Windows 7 then I might have something for you…
I know that you would, at least like to feel that Win 7 design if you can’t use the Windows 7 itself. All those newly designed features like big and iconized taskbar buttons, Windows 7 Superbar, or even full Start ORB. Now you can have all that in Windows XP too. (cool ins’t it?)
Here’s how your desktop will look like after you complete the steps below:
And here’s how to make it possible:
1. Download SevenVG Refresh Theme here and extract its contents. You should see a folder named: “SevenVG Refresh Theme for Windows XP by Vishal Gupta“.
2. In this folder, you’ll get 3 more folders:
a) Fonts (This folder contains Segoe UI fonts required for the theme. Run Fonts.exe file to install them.)
b) Styler Toolbar (This folder contains Styler setup and SevenVG styler toolbar skin. It will provide toolbar and commandbar in Explorer that looks like Windows 7)
c) Theme (This folder contains the main theme. Run “Theme.exe” file to install it.)
3. Apply the theme using Desktop Properties and you’re ready to go! Enjoy!
4. Also make sure you have patched the “uxtheme.dll” file (needs to be patched to allow 3rd party visual styles), if it’s not patched, then download and run the UXtheme Patcher from here:
For XP SP3 Users - Download UXTheme Patcher here
For XP SP2 Users - Download UXTheme Patcher here
Ok, you applied the new theme. But now you need to make iconized taskbar buttons on your XP to look just like on Windows 7.
How to make iconized taskbar buttons on your XP:
Windows 7 taskbar doesn’t show text in application buttons, it only show their icons. Here’s how it will look like after you follow these steps:
And as you already know, previous Windows versions used to show icon as well as text in all application’s taskbar buttons. That takes too much space when you open lot of applications. And here is how it looks (although you know how it looks because you are using it now, but just for the record…)
As you can see, Windows 7 new iconized taskbar feature looks cool and it also saves a lot of space in the taskbar area.
There are 2 ways to do this.
1. Download a registry file that will automatically make necessary changes in your registry base and make your toolbar look like in the image above (the easy way - strongly recommended)
2. Manually make the changes in your Windows registry base to apply the above effect. (Only for advanced users - not really recommended).
I hope you have chosen the easy way (as we all do when choosing to do things in life right?), but if you really insist that you want to do it yourself, manually, then here’s how to do it:
1. Type regedit in RUN dialog box and press Enter. It’ll open Registry Editor. Now go to following key:
HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics
2. In right-side panel, create a new String value MinWidth and set its value to -255
3. That’s it. Log off or restart your system and get ready to have iconized taskbar in your system.
4. To restore the default taskbar behavior, delete the MinWidth String value and log off or restart your system.
That’s all you need to do to make that XP desktop look as shiny and cool looking as Windows 7.
Credits for theme created to Vistart skin at DevianArt.
Enjoy! And don’t forget to share this post if you like it
Unlocking WinXP's setupp.ini
Unlocking WinXP's setupp.ini
WinXP's setupp.ini controls how the CD acts. IE is it an OEM version or retail? First, find your setupp.ini file in the i386 directory on your WinXP CD. Open it up, it'll look something like this:
ExtraData=707A667567736F696F697911AE7E05
Pid=55034000
The Pid value is what we're interested in. What's there now looks like a standard default. There are special numbers that determine if it's a retail, oem, or volume license edition. First, we break down that number into two parts. The first five digits determines how the CD will behave, ie is it a retail cd that lets you clean install or upgrade, or an oem cd that only lets you perform a clean install? The last three digits determines what CD key it will accept. You are able to mix and match these values. For example you could make a WinXP cd that acted like a retail cd, yet accepted OEM keys.
Now, for the actual values. Remember the first and last values are interchangable, but usually you'd keep them as a pair:
Retail = 51882335
Volume License = 51883 270
OEM = 82503 OEM
So if you wanted a retail CD that took retail keys, the last line of your setupp.ini file would read:
Pid=51882335
And if you wanted a retail CD that took OEM keys, you'd use:
Pid=51882OEM
Note that this does NOT get rid of WinXP's activation. Changing the Pid to a Volume License will not bypass activation. You must have a volume license (corporate) key to do so.
raihan
WinXP's setupp.ini controls how the CD acts. IE is it an OEM version or retail? First, find your setupp.ini file in the i386 directory on your WinXP CD. Open it up, it'll look something like this:
ExtraData=707A667567736F696F697911AE7E05
Pid=55034000
The Pid value is what we're interested in. What's there now looks like a standard default. There are special numbers that determine if it's a retail, oem, or volume license edition. First, we break down that number into two parts. The first five digits determines how the CD will behave, ie is it a retail cd that lets you clean install or upgrade, or an oem cd that only lets you perform a clean install? The last three digits determines what CD key it will accept. You are able to mix and match these values. For example you could make a WinXP cd that acted like a retail cd, yet accepted OEM keys.
Now, for the actual values. Remember the first and last values are interchangable, but usually you'd keep them as a pair:
Retail = 51882335
Volume License = 51883 270
OEM = 82503 OEM
So if you wanted a retail CD that took retail keys, the last line of your setupp.ini file would read:
Pid=51882335
And if you wanted a retail CD that took OEM keys, you'd use:
Pid=51882OEM
Note that this does NOT get rid of WinXP's activation. Changing the Pid to a Volume License will not bypass activation. You must have a volume license (corporate) key to do so.
raihan
Turn off Welcome screen
Open User Accounts in Control Panel.
Click Change the way users log on or off
raihan
Click Change the way users log on or off
raihan
User Accounts and Fast User Switching
User Accounts and Fast User Switching
Introduction
Windows XP represents Microsoft's big push to get the largely Windows 9X-based user community to an operating system family based on the Windows NT-kernel. In Windows XP, new client services not only blend the ease of use of familiar Windows 9X profiles with the robustness of Windows NT (and Windows 2000) user management, but significantly improve on the combination. While the majority of these advancements will be appreciated most by home users, enterprise customers that share assets-for instance, with shift workers and telecommuters or with users who access e-mail from multiple machines while roaming-will also see improvements.
Many computers are shared between multiple users, particularly in the home environment where studies have shown that 80% of computers are used routinely by multiple people. In previous versions of Windows NT, user account management-which could be strictly enforced across the enterprise by administrators-was a somewhat tricky process that was beyond the abilities of most non-computing professionals. Simple-to-use Windows 9X profiles, however, were not enabled by default and were largely ignored: The cost of actually using the profiles, which required that users log off before allowing other users to access the system, meant that the vast majority of machines made do with a single shared profile, with all of the corresponding security, configuration, and data-loss risks.
In Windows XP, user profiles are always enabled and even non-enterprise users are encouraged to create accounts during the Setup process. These accounts are based on Windows NT profiles and allow Windows XP to provide strong isolation and protection of users' data and settings. If multiple user accounts are configured on a machine, then users are presented with a Welcome screen that appears featuring separate-and customizable-graphics for each user. Users of Windows XP machines that are members of an NT-style domain do not see this screen, since presenting a list of machine users could be considered a security violation. A new control panel applet replaces the familiar Windows NT User Manager and Windows 2000 Computers and Users snap-in, providing a simple interface that allows almost anyone to set up a new user and give them appropriate rights and privileges.
Fast User Switching
Windows XP introduces fast user switching. Undoubtedly, fast user switching is the single most important feature that makes sharing Windows-based computers workable. Using fast user switching, it is not necessary for a user to log off the computer before allowing a second user to access their own account. Instead, the first user's account is "disconnected," which leaves all the programs running; the second user can then log on, and then the users can switch quickly between logged-on accounts. Many accounts can be open simultaneously on one computer, though only one account at a time will be able to interact with the keyboard, screen, and input devices.
In the home environment, for instance, fast user switching allows a parent working on a personal finance program to yield the computer to a child to work on homework by browsing the Internet, without requiring the parent to shut down and restart the finance program and without exposing the child to the parent's financial information. In the business environment, fast user switching can allow multiple users in a common environment, such as a research lab, to share a single machine.
Fast user switching is just one of two mechanisms that allow multiple users to work with a single system. Remote desktop, another built-in Windows XP feature, allows users to interact with machines remotely across a network and to access data and applications on those remote machines. While fast user switching is aimed principally at the home market, remote desktop enables business users to access their corporate desktops from remote computers-and vice versa, enabling them to operate home machines while at work.
Programming Issues
Both fast user switching and remote desktop use Windows XP's updated terminal services technology. Improvements have been made to both the server and client components of terminal services. Windows XP now features support for both local and remote sound, 24-bit video, performance optimizations, and the mapping of the local drives and printers.
Fortunately, most applications don't have to be rewritten to work with terminal services and, thus, fast user switching and remote desktop. Rather, they need to respect basic user settings management guidelines. These guidelines are not new: Most are covered in the Windows 2000 Certified for Windows Application Specification, which has been available on Microsoft's Web site for some time. The Data and Settings Management section of this specification includes several topics that are particularly important when supporting multiple users on a single machine:
· Default to the My Documents folder for storage of user-created data;
· Classify and store application data correctly;
· Degrade gracefully on "Access denied" messages.
Mostly, this means isolating data and settings for each user. And an important step in this direction is to ensure that you are using the HKEY_CURRENT_USER registry key rather than HKEY_LOCAL_MACHINE for storing settings in the system registry. You should also be careful to install programs correctly and to classify and store data correctly. You can use the ShGetFolderPath API to obtain the path of a specific named folder-such as "My Documents" or even "Program Files"-as well as the appropriate directories for storing Roaming, Non-Roaming, and Shared application data. The following are some general guidelines for locating data:
· Profiles\username\Application Data\appname
- Roaming, auto-created user files (e-mail DB, custom dictionaries…)
· Profiles\username\Application Data\Local Settings\appname
- Discardable/local-only user data files (e.g., offline stores)
· Profiles\All Users\Application Data\appname
- Last-resort for local-only, common dynamic data (e.g., log files)
A notable exception to the isolation rule is that you should support "All Users" installations: It is extremely frustrating for users to install the same application repeatedly for multiple user accounts.
By carefully locating user data, user settings, and computer settings, applications can make it easier for users to backup individual documents and settings, share a computer among multiple users, and even to work with the same documents and settings on multiple computers. By handling data and settings properly, you can enable your application to run in both the home (fast user switching) and business enterprise (remote desktop) marketplaces.
Controlling Running Instances
It is common for applications to control their startup so that only a single instance may be running on a machine at any given time. There are many valid reasons for doing this: licensing restrictions, required dedicated access to specific hardware resources, and perhaps even enforcing data integrity. However, with multiple users on the same machine, it might be desirable to allow multiple users-each with their own instance-to work with (for example) a personal finance program as long as their data remains isolated. At this point, the commonly used mechanisms for controlling running instances may exhibit some unwanted side effects when operating under Windows XP's fast user switching or remote desktop.
The most common method for discovering whether another instance is running is to use the FindWindow or FindWindowEx APIs to search for a window that, if your application is running, you know to be open. Somewhat unexpectedly, both of these APIs work in a single user session only. So using this method won't prevent another instance of your application from being started by another user.
A more robust method for controlling multiple instances is to use one of the NT kernel objects: events, semaphores, mutexes, waitable timers, file-mapping objects, and job objects can all be used with Global\ or Local\ prefixes on Windows 2000 and Windows XP. By default, each user (terminal service) session will have its own namespace for kernel objects. By creating a Global\ object-for instance, a mutex or semaphore-when your application is started (and closing it upon exit), your application can detect running instances across multiple user (terminal service) sessions. Of course, you can't just switch to the previous instance: It may be in another session! What typically happens in that case is the user clicks on an icon and then nothing appears to happen (since the app thinks it's located another running instance). At a minimum, you should warn the user that there's another instance running.
What about sound? Well, the terminal services in Windows XP have been designed to configure sound to both the interactive and disconnected sessions. While it may be difficult to imagine at first, there may be valid scenarios where it would desirable to output multiple audio streams. For instance, what if you used a sound card in one user session to output audio to the home stereo system and at the same time the active user wanted to hold an interactive meeting with sound? In this case, you certainly would not want to blend the two streams. And neither would you want to suspend the audio stream in the disconnected session. Getting this right can be particularly important when working with shared media devices like DVD players.
One general guideline is to do "as little as possible, as much as necessary" when you are the disconnected session. To do this, it can be helpful to know when a session switch occurs. While most applications won't need to be notified, if your application accesses a shared resource-such as a serial port or other hardware device-you may want to know when the machine switches between user sessions. To be notified when a session switch occurs, you must register to receive the WM_WTSSESSION_CHANGE message by calling the WTSRegisterConsoleNotification API. Using this function, you can choose to be notified for a single session or for all sessions, and when either local or remote sessions connect or disconnect. When you no longer require notification, you should unregister using the WTSUnRegisterConsoleNotification API.
Summary
If you isolate access to your application's data and settings and take care not to tie up shared resources, your application should work well with Windows XP's terminal services. By developing your application to assume it's not the only thing running on the machine, your users are likely to have a much better experience when they start using it with Windows XP's new fast user switching and remote desktop features raihan
Introduction
Windows XP represents Microsoft's big push to get the largely Windows 9X-based user community to an operating system family based on the Windows NT-kernel. In Windows XP, new client services not only blend the ease of use of familiar Windows 9X profiles with the robustness of Windows NT (and Windows 2000) user management, but significantly improve on the combination. While the majority of these advancements will be appreciated most by home users, enterprise customers that share assets-for instance, with shift workers and telecommuters or with users who access e-mail from multiple machines while roaming-will also see improvements.
Many computers are shared between multiple users, particularly in the home environment where studies have shown that 80% of computers are used routinely by multiple people. In previous versions of Windows NT, user account management-which could be strictly enforced across the enterprise by administrators-was a somewhat tricky process that was beyond the abilities of most non-computing professionals. Simple-to-use Windows 9X profiles, however, were not enabled by default and were largely ignored: The cost of actually using the profiles, which required that users log off before allowing other users to access the system, meant that the vast majority of machines made do with a single shared profile, with all of the corresponding security, configuration, and data-loss risks.
In Windows XP, user profiles are always enabled and even non-enterprise users are encouraged to create accounts during the Setup process. These accounts are based on Windows NT profiles and allow Windows XP to provide strong isolation and protection of users' data and settings. If multiple user accounts are configured on a machine, then users are presented with a Welcome screen that appears featuring separate-and customizable-graphics for each user. Users of Windows XP machines that are members of an NT-style domain do not see this screen, since presenting a list of machine users could be considered a security violation. A new control panel applet replaces the familiar Windows NT User Manager and Windows 2000 Computers and Users snap-in, providing a simple interface that allows almost anyone to set up a new user and give them appropriate rights and privileges.
Fast User Switching
Windows XP introduces fast user switching. Undoubtedly, fast user switching is the single most important feature that makes sharing Windows-based computers workable. Using fast user switching, it is not necessary for a user to log off the computer before allowing a second user to access their own account. Instead, the first user's account is "disconnected," which leaves all the programs running; the second user can then log on, and then the users can switch quickly between logged-on accounts. Many accounts can be open simultaneously on one computer, though only one account at a time will be able to interact with the keyboard, screen, and input devices.
In the home environment, for instance, fast user switching allows a parent working on a personal finance program to yield the computer to a child to work on homework by browsing the Internet, without requiring the parent to shut down and restart the finance program and without exposing the child to the parent's financial information. In the business environment, fast user switching can allow multiple users in a common environment, such as a research lab, to share a single machine.
Fast user switching is just one of two mechanisms that allow multiple users to work with a single system. Remote desktop, another built-in Windows XP feature, allows users to interact with machines remotely across a network and to access data and applications on those remote machines. While fast user switching is aimed principally at the home market, remote desktop enables business users to access their corporate desktops from remote computers-and vice versa, enabling them to operate home machines while at work.
Programming Issues
Both fast user switching and remote desktop use Windows XP's updated terminal services technology. Improvements have been made to both the server and client components of terminal services. Windows XP now features support for both local and remote sound, 24-bit video, performance optimizations, and the mapping of the local drives and printers.
Fortunately, most applications don't have to be rewritten to work with terminal services and, thus, fast user switching and remote desktop. Rather, they need to respect basic user settings management guidelines. These guidelines are not new: Most are covered in the Windows 2000 Certified for Windows Application Specification, which has been available on Microsoft's Web site for some time. The Data and Settings Management section of this specification includes several topics that are particularly important when supporting multiple users on a single machine:
· Default to the My Documents folder for storage of user-created data;
· Classify and store application data correctly;
· Degrade gracefully on "Access denied" messages.
Mostly, this means isolating data and settings for each user. And an important step in this direction is to ensure that you are using the HKEY_CURRENT_USER registry key rather than HKEY_LOCAL_MACHINE for storing settings in the system registry. You should also be careful to install programs correctly and to classify and store data correctly. You can use the ShGetFolderPath API to obtain the path of a specific named folder-such as "My Documents" or even "Program Files"-as well as the appropriate directories for storing Roaming, Non-Roaming, and Shared application data. The following are some general guidelines for locating data:
· Profiles\username\Application Data\appname
- Roaming, auto-created user files (e-mail DB, custom dictionaries…)
· Profiles\username\Application Data\Local Settings\appname
- Discardable/local-only user data files (e.g., offline stores)
· Profiles\All Users\Application Data\appname
- Last-resort for local-only, common dynamic data (e.g., log files)
A notable exception to the isolation rule is that you should support "All Users" installations: It is extremely frustrating for users to install the same application repeatedly for multiple user accounts.
By carefully locating user data, user settings, and computer settings, applications can make it easier for users to backup individual documents and settings, share a computer among multiple users, and even to work with the same documents and settings on multiple computers. By handling data and settings properly, you can enable your application to run in both the home (fast user switching) and business enterprise (remote desktop) marketplaces.
Controlling Running Instances
It is common for applications to control their startup so that only a single instance may be running on a machine at any given time. There are many valid reasons for doing this: licensing restrictions, required dedicated access to specific hardware resources, and perhaps even enforcing data integrity. However, with multiple users on the same machine, it might be desirable to allow multiple users-each with their own instance-to work with (for example) a personal finance program as long as their data remains isolated. At this point, the commonly used mechanisms for controlling running instances may exhibit some unwanted side effects when operating under Windows XP's fast user switching or remote desktop.
The most common method for discovering whether another instance is running is to use the FindWindow or FindWindowEx APIs to search for a window that, if your application is running, you know to be open. Somewhat unexpectedly, both of these APIs work in a single user session only. So using this method won't prevent another instance of your application from being started by another user.
A more robust method for controlling multiple instances is to use one of the NT kernel objects: events, semaphores, mutexes, waitable timers, file-mapping objects, and job objects can all be used with Global\ or Local\ prefixes on Windows 2000 and Windows XP. By default, each user (terminal service) session will have its own namespace for kernel objects. By creating a Global\ object-for instance, a mutex or semaphore-when your application is started (and closing it upon exit), your application can detect running instances across multiple user (terminal service) sessions. Of course, you can't just switch to the previous instance: It may be in another session! What typically happens in that case is the user clicks on an icon and then nothing appears to happen (since the app thinks it's located another running instance). At a minimum, you should warn the user that there's another instance running.
What about sound? Well, the terminal services in Windows XP have been designed to configure sound to both the interactive and disconnected sessions. While it may be difficult to imagine at first, there may be valid scenarios where it would desirable to output multiple audio streams. For instance, what if you used a sound card in one user session to output audio to the home stereo system and at the same time the active user wanted to hold an interactive meeting with sound? In this case, you certainly would not want to blend the two streams. And neither would you want to suspend the audio stream in the disconnected session. Getting this right can be particularly important when working with shared media devices like DVD players.
One general guideline is to do "as little as possible, as much as necessary" when you are the disconnected session. To do this, it can be helpful to know when a session switch occurs. While most applications won't need to be notified, if your application accesses a shared resource-such as a serial port or other hardware device-you may want to know when the machine switches between user sessions. To be notified when a session switch occurs, you must register to receive the WM_WTSSESSION_CHANGE message by calling the WTSRegisterConsoleNotification API. Using this function, you can choose to be notified for a single session or for all sessions, and when either local or remote sessions connect or disconnect. When you no longer require notification, you should unregister using the WTSUnRegisterConsoleNotification API.
Summary
If you isolate access to your application's data and settings and take care not to tie up shared resources, your application should work well with Windows XP's terminal services. By developing your application to assume it's not the only thing running on the machine, your users are likely to have a much better experience when they start using it with Windows XP's new fast user switching and remote desktop features raihan
XP to directly access WebDAV "internet disks"
Windows XP can directly access WebDAV "internet disks" such as Apple's iDisk.
In Internet Explorer, use the "Open..." command, type the name of the WebDAV server you want to access (e.g., http://idisk.mac.com/username) and select the "Open as Web Folder" checkbox. Enter the password when prompted and you're in!
This trick also works on Windows Me and Windows 2000. Interestingly, Windows XP doesn't seem to support iDisk via the "Add a Network Place" command, possible with these other operating systems.
Once set up using the "Open" command, however, the idisk can be accessed by simply double-clicking its icon in the Network Places folder.
raihan
In Internet Explorer, use the "Open..." command, type the name of the WebDAV server you want to access (e.g., http://idisk.mac.com/username) and select the "Open as Web Folder" checkbox. Enter the password when prompted and you're in!
This trick also works on Windows Me and Windows 2000. Interestingly, Windows XP doesn't seem to support iDisk via the "Add a Network Place" command, possible with these other operating systems.
Once set up using the "Open" command, however, the idisk can be accessed by simply double-clicking its icon in the Network Places folder.
raihan
How to Write a Windows XP Driver
How to Write a Windows XP Driver
Source: Microsoft Corporation July 2001
Summary: This document describes the steps you should take to create a Microsoft® Windows® XP driver for your device. To create a Windows XP device driver:
Install the current Windows DDK. Read the system requirements and installation instructions in the stand-alone Getting Started HTML file supplied with the DDK.
Read Getting Started with Windows Drivers. This document guides you through the planning and decision-making process involved in making a Windows device driver from design through distribution. You should also look through the DDK documentation for device-type-specific information.
The DDK documentation set has the following device-type-specific nodes:
Battery Devices
Display and Print Devices
IEEE 1284.4 Devices
Interactive Input Devices
Modem Devices
Multifunction Devices
Network Devices and Protocols
Parallel Ports and Devices
Serial Ports and Devices
Smart Card Devices
Still Image Devices
Storage Devices
Streaming Devices (Video and Audio)
Devices Requiring VDDs
IDE bus are described in System Support for Buses. Driver development for most device types also requires a strong understanding of Windows operating system fundamentals, which are described in Kernel-Mode Driver Architecture.
Look through the driver source code provided with the DDK for a sample that represents your device type. Use the sample code where possible, modifying it for your device's specifics.
The sample code can enhance your understanding of Windows XP driver implementation requirements and speed your development time.
Compile and build your driver. This should be done using the Build utility and not some other compiler, because the Build utility has certain features that are necessary for driver development.
Obtain a checked build of Windows XP, so that you can test and debug your driver using free and checked system builds.
The checked build of Windows XP provides extensive kernel-mode debugging capabilities not available in the free build.
Create an INF file so that you can install and test your driver.
Test and debug your driver. You should use Driver Verifier, a program that puts your driver through a variety of tests, stresses, and deliberate failures in order to test its response and reliability in many extreme situations. You should also use a debugger. Microsoft provides several powerful debuggers that can monitor and debug kernel-mode and user-mode drivers.
Using Driver Verifier in conjunction with these debuggers, on both the checked and free versions of the operating system, can be a powerful way to test your driver.
Provide an installation package so that customers can install devices that use your driver.
Submit your driver and installation package to Microsoft so that it can be digitally signed.
There are many resources available to you while developing your driver. The following sites describe some of the support available to you:
http://www.microsoft.com/ddk describes how to obtain the current DDK and provides other information, such as a driver development reading list.
http://www.microsoft.com/hwdev provides information, such as device-type-specific white papers and late-breaking news, and a list of resources available to driver developers.
http://support.microsoft.com/support/ddk contains DDK product support information.
raihan
Source: Microsoft Corporation July 2001
Summary: This document describes the steps you should take to create a Microsoft® Windows® XP driver for your device. To create a Windows XP device driver:
Install the current Windows DDK. Read the system requirements and installation instructions in the stand-alone Getting Started HTML file supplied with the DDK.
Read Getting Started with Windows Drivers. This document guides you through the planning and decision-making process involved in making a Windows device driver from design through distribution. You should also look through the DDK documentation for device-type-specific information.
The DDK documentation set has the following device-type-specific nodes:
Battery Devices
Display and Print Devices
IEEE 1284.4 Devices
Interactive Input Devices
Modem Devices
Multifunction Devices
Network Devices and Protocols
Parallel Ports and Devices
Serial Ports and Devices
Smart Card Devices
Still Image Devices
Storage Devices
Streaming Devices (Video and Audio)
Devices Requiring VDDs
IDE bus are described in System Support for Buses. Driver development for most device types also requires a strong understanding of Windows operating system fundamentals, which are described in Kernel-Mode Driver Architecture.
Look through the driver source code provided with the DDK for a sample that represents your device type. Use the sample code where possible, modifying it for your device's specifics.
The sample code can enhance your understanding of Windows XP driver implementation requirements and speed your development time.
Compile and build your driver. This should be done using the Build utility and not some other compiler, because the Build utility has certain features that are necessary for driver development.
Obtain a checked build of Windows XP, so that you can test and debug your driver using free and checked system builds.
The checked build of Windows XP provides extensive kernel-mode debugging capabilities not available in the free build.
Create an INF file so that you can install and test your driver.
Test and debug your driver. You should use Driver Verifier, a program that puts your driver through a variety of tests, stresses, and deliberate failures in order to test its response and reliability in many extreme situations. You should also use a debugger. Microsoft provides several powerful debuggers that can monitor and debug kernel-mode and user-mode drivers.
Using Driver Verifier in conjunction with these debuggers, on both the checked and free versions of the operating system, can be a powerful way to test your driver.
Provide an installation package so that customers can install devices that use your driver.
Submit your driver and installation package to Microsoft so that it can be digitally signed.
There are many resources available to you while developing your driver. The following sites describe some of the support available to you:
http://www.microsoft.com/ddk describes how to obtain the current DDK and provides other information, such as a driver development reading list.
http://www.microsoft.com/hwdev provides information, such as device-type-specific white papers and late-breaking news, and a list of resources available to driver developers.
http://support.microsoft.com/support/ddk contains DDK product support information.
raihan
XP to directly access WebDAV "internet disks"
Windows XP can directly access WebDAV "internet disks" such as Apple's iDisk.
In Internet Explorer, use the "Open..." command, type the name of the WebDAV server you want to access (e.g., http://idisk.mac.com/username) and select the "Open as Web Folder" checkbox. Enter the password when prompted and you're in!
This trick also works on Windows Me and Windows 2000. Interestingly, Windows XP doesn't seem to support iDisk via the "Add a Network Place" command, possible with these other operating systems.
Once set up using the "Open" command, however, the idisk can be accessed by simply double-clicking its icon in the Network Places folder.
raihan
In Internet Explorer, use the "Open..." command, type the name of the WebDAV server you want to access (e.g., http://idisk.mac.com/username) and select the "Open as Web Folder" checkbox. Enter the password when prompted and you're in!
This trick also works on Windows Me and Windows 2000. Interestingly, Windows XP doesn't seem to support iDisk via the "Add a Network Place" command, possible with these other operating systems.
Once set up using the "Open" command, however, the idisk can be accessed by simply double-clicking its icon in the Network Places folder.
raihan
এতে সদস্যতা:
পোস্টগুলি (Atom)
