The no-cal versions have vast quantities of strange sweeteners.
Actually, most artificial sweeteners are much sweeter than glucose, so only a tiny quantity is needed. Sucralose for example is 600 times sweeter than sugar. Wikipedia has a nice table on the subject.
I'm not sure what "strange" is supposed to mean. There are many thousands of different chemicals present in organic foods. Many sugar substitutes are chemicals that were discovered in food plants in the first place.
No, Microsoft needed to split with the past APIs (.NET, win32, COM, etc) and build a single one to replace them all.
If you're referring to WinRT, it's just another facade over Win32 (like.NET is, not that.NET is going anywhere) that is leaking ugly Win32 compatibility warts like MAX_PATH. The API layer beneath Win32, the native kernel syscall API, does not have have that restriction. FYI, WinRT uses COM to define WinRT, so that's not going anywhere either. If they're building their shiny new API on top of a different existing middle layer (Win32), I don't see it becoming independent or a split with the past.
I'm seriously NOT trolling; but I've personally always found it fascinating that Apple, THE company that, if nothing else, POPULARIZED the GUI interface (see that trick for avoiding the "Apple ripped-off Xerox" flamewars?), not only is REFUSING to buy-into the "Touch desktop/laptop" drumbeat, but significantly, actually has a MUCH more robust set of "Keyboard Shortcuts" than Windows (See this eye-popping list. Shades of Emacs!!!). I have scoured the web (admittedly for only 5 minutes), and I can't come up with a list of Windows OS Shortcuts (that doesn't include application-specific shortcuts) that is nearly as lengthy. Heck, Windows 8 doesn't even have a keyboard shortcut for Shut Down. Sure, you can DO it; but it's a multi-step procedure...
I don't agree that OSX has better keyboard shortcuts than Windows. There are several things that have no default key or can't be done with the keyboard alone on OSX (except possibly with 3rd party software) For example:
Open a context menu where the keyboard focus is. Windows: there's a special menu key for that! Or you can use SHIFT+F10. OSX: None and apparently there's not even a 3rd party program to do that.
Move a window. Windows: ALT+SPACE,M,<arrow keys>. OSX: None.
Resize a window. Windows: ALT+SPACE,S,<arrow keys>. OSX: None.
Maximize/zoom. Windows: ALT+SPACE,X. Restore: ALT+SPACE,R. OSX: You can make a global shortcut key to Zoom that works with apps that have a Zoom menu option. If you resize the window after it's zoomed, it won't unzoom to its original size though.
Minimize/hide. Windows: ALT+SPACE,N. OSX: you can make your own shortcut key but it doesn't work for all apps.
Task manager/activity monitor. Windows:CTRL+SHIFT+ESC. OSX: You have to create a key yourself.
Run an arbitrary command line. Windows: WIN+R. OSX: None.
Most of those have been around since Windows 3 or Windows 95 for the ones using the menu or Windows keys.
I don't actually use "shut down" or "restart" that often, so I hardly need a shortcut key for them, but a sequence that has worked since Windows 95 is WINKEY,ESC,ALT+F4 and then you have a listbox of options you can type into to select an option. Press Enter to perform the selected operation.
Both OSes have common conventions as well as guidelines produced by Apple and Microsoft. Different ISVs and apps follow those to different degrees, but there are still differences in convention. In particular, you can hit ALT in Windows to access the menu bar, each menu and menu item will have an underlined shortcut key. Dialog boxes also have ALT+ shortcuts by doing the same thing, and you can click the default button with Enter and the cancel button with Esc. Even ribbons have key sequences for every option.
The Nokia N900's OS, Maemo 5, is based on Debian and uses apt as its package manager. You can add http://repository.maemo.org/extras/ and related repositories right in the application manager UI (which is just a fancy interface for apt). The OS updates can even be done with apt-get dist-upgrade. You can even install a chrooted real Debian environment and pull random packages from the Debian repositories. And yes, pulling stuff off of apt-get is beautiful.
I didn't write the original post. I chimed in to say that you don't actually have to specify the threads and details of communication with GHC's parallelization extensions.
There is no general purpose programming environment that I know of that completely automates parallel execution. Also, with ANY programming environment, you can make a very inefficient program if you do things unwisely. For that matter, some programming environments or styles are very different and it takes rewriting to adapt existing code properly.
It's all about how easy and effectively the tools make it to do what you want. I think that GHC is among the leaders in concepts for parallel programming. The actual runtime performance is pretty good too, especially if you are willing to put some work into it.
With DPH, I am under the impression (I've used it very little so far, so maybe I'm wrong) that you use the parallel arrays pervasively within the program (any place a strict finite list would do) and the compiler will do most of the work in determining when parallel execution is worth it. Also, Erlang's recommend style of many small processes scales very easily; the runtime will decide when to call through and when to allocate those processes to separate threads. These aren't quite automatic, but it's a LOT closer than the traditional thread & semaphore model.
I've programmed quite a bit in Haskell. GHC is the most popular compiler by far and it implements all the latest parallelization and concurrency extensions (The last standard, Haskell 98, doesn't specify anything in this area).
There are two approaches to using multiple cores in GHC:
Concurrency; which ranges from explicitly created threads (either OS threads or lightweight runtime scheduled threads or some combination) that communicate through channels or locked variables or another traditional method, to STM.
The other is parallelism. Whereas the concurrency methods all use monads to sequence and control operations and produce code that looks more like that of an imperative language, parallelism is done entirely in pure functional code. The short description of pure functional is that all data is immutable. This is very useful for parallel execution because it greatly simplifies evaluation dependencies. You don't have to worry about modifying things in the right order or change conflicts because nothing is allowed to be mutated in the first place. This enables non-strict evaluation, which means that the various values in a program (even those nested in data structures) can be evaluated at any time during program execution, and in any order (as long as they are evaluated by the time they're needed). Parallel approaches include:
Simple use of par and seq. seq ties the evaluation of one term to another, to force a term to be evaluated immediately even if it isn't strictly needed yet. par creates a "spark" to evaluate a value. This spark may be executed by a different runtime thread than is currently running. Together, you can specify one value to be evaluated locally and another to be potentially evaluated by another CPU. This will work well if the values are reasonably expensive to evaluate (otherwise the overhead of creating the spark, while small, will be greater than the benefits) and independent. Can easily be used with e.g. evaluating all the elements in a list in parallel; runtime threads will pick up and execute the sparks as they are created.
Parallel strategies. Create an evaluation strategy that mirrors the layout of your program, identifying the parts that can benefit from executing in parallel.
Data parallel Haskell is an upcoming method that allows you to define parallel array structures that the compiler can see through to determine vectorized evaluation strategies.
In short, none of Haskell's methods of parallelization require you to be aware of threads or synchronization.
Windows NT 3.1 actually introduced Win32 first in 1993, with limited user accounts, profiles and the registry (which was the standard location for configuration). The documentation for Windows 95 marked a lot of Win32 APIs as not available, but it still specified that all application configuration should go into separate user and machine registry hives depending on the scope of the setting. Microsoft published guidelines and made them a requirement for getting the Windows 95 logo, but Microsoft has never had the power to force ISVs to do things a certain way. One choice that didn't help was that Win95 didn't implement any security to keep the OS small and simple, which hid a lot of application design problems down the road.
There are a lot of programs that have problems on newer Windows OSes that were written for earlier versions, but examples of applications that have problems even though they followed the guidelines for the OS version they were written for are extremely rare.
I once went looking to see if there was a way to do it from within the application code itself - something like mlock()/mlockall() in posix - and I couldn't find an equivalent, which may just be a reflection of my own inexperience with the Windows API but I figured I would throw that out there anyway.
The function you're looking for is VirtualLock. You may also look into increasing the process's minimum working set with SetProcessWorkingSetSize. This requires SeIncreaseBasePriorityPrivilege.
A process that is scanning through a file is supposed to use the FILE_FLAG_SEQUENTIAL_SCAN hint so that the cached pages are recycled first, but that doesn't always happen. It also doesn't help that csrss will ask the kernel to minimize a process's working set when its main window is minimized.
I don't know that it's documented in detail anywhere. The beginning priority seems to be based on the process's priority (5 for normal apparently) and is adjusted by usage heuristics and superfetch. There is a overview here. It may help to raise the priority of FF to AboveNormal if it seems like its pages are being discarded unnecessarily.
What the other posters said in reply to your other post about the OS not really knowing what memory belongs to what tab, instead having a page level view of things, is correct. When the CPU accesses a page, it sets a flag in the page descriptor that the page was accessed. The memory manager checks these flags periodically to see what pages are being used. When the MM thinks the process has too many pages, it takes away those that haven't had that flag set in a while. I guess the frequency of usage has some effect on the priority, but I'm not sure.
But "page out" means something in RAM is going to disk - if I ever want it back in RAM, I'll have to wait.
On Windows it doesn't necessarily mean that. Writing a page to disk != needing to read it back from disk later.
Each process has a working set. Pages in the working set are mapped actively into the process's VM with page tables. The memory manager aggressively trims these pages from the working set and puts them into standby memory. A page in standby is not mapped for reading (and more importantly for writing) anywhere in the system. Part of putting the page into standby involves writing a copy to disk. This will show up as a page written.
From standby, the page can be used one of two ways:
Transitioned back. If one of the processes that originally had the page mapped touches the page, it will cause a soft page fault in which the page is simply put back in the process's page directory. There's no need to retrieve it from disk since it still has the same data from before. The disk copy is discarded. This will show up as a transition fault in the performance monitor.
Reused for something else. Standby pages are counted as "Available" because they can be immediately re-used for another purpose without accessing the disk. The memory copy of the page is discarded and the page is re-used for something else. No disk activity is needed at this time since there is already a copy on disk. When one of the original owners of the page want the data back and the page is no longer on standby, it has to be retrieved from disk. This will count as a page fault in the performance monitor.
The nice thing about this model is that disk activity isn't needed to either reuse pages or bring them back at the time of the demand. It helps avoid the ugly condition of paging one process out while paging another in at the same time, causing disk thrashing.
Since Vista, the memory manager will preemptively re load pages that have been bumped out of standby back into standby if there is
free unused memory available. Also since Vista, each page of memory has a priority from 0-7 that determines which pages are preferred to keep in RAM. In all versions of NT based Windows, memory mapping is very similar to page file management and will use many of the same counters (including standby memory, transition and hard faults, pages in/out). Memory mapping is used by lots of components internally and for loading executable images and libraries. Also, file caching is logically based in many ways on memory mapping, although the counters are different in many cases.
The OS is Maemo 5 "Fremantle", which is based on Debian (and BusyBox), but some of the ways it's set up aren't fully compatible with a lot of Debian standard software. I don't think you can just add the Debian ARM repositories directly and install stuff. Packages have to be tested and sometimes modified to work natively.
However, it is popular to create a real Debian environment with chroot, which works around that problem. See Easy Debian, which is a package that does all the work in setting that up, including OpenOffice.org, GIMP, LXDE and an environment you really can apt-get install most anything from the Debian mainline into.
I've had a N900 since December. I'm very happy with it. Installed Easy Debian and OpenOffice and they work quite well. There's only so much word processing I want to do on a platform that size, but it's great for modifying office email attachments on occasion. Having a spreadsheet in my pocket is quite handy too. Stylus is recommended but not compulsory. It's still in testing and there are a few headaches, like some dialogs being too tall to properly reach the buttons at the bottom, but it's already improved a lot from previous versions and I expect it to get even better.
As for the community, the main forums don't look dead to me. Have a look at the packages they offer.
IE6 is the only browser supported where I work, you insensitive clod! (It's the latest version available for Windows 2000. Plus there are corporate web apps that only work properly with IE6.)
There is a keywords field under summary (since Win2k actually). The volume will need to be NTFS, since those extra properties are stored in alternate data streams. I believe that it's indexed. I think you use the "tag:" prefix to find them.
I don't know why this reply is labeled redundant except to show a bias against stating a legitimate concerns and problems with Wikipedia. It sounds like there is a broken mod system here on/. as well. Not that this is also stating the obvious.
It could be that the post just before that one by Nwallins (1059978) on 2009.11.25 13:41 (#30228784) makes the same mention of http://en.wikipedia.org/wiki/Wikipedia:Be_bold. I wouldn't have marked either as redundant though because the other was first and the second one has more material.
I also wouldn't say that/.'s moderation system was too far gone or biased on this topic. This story seems to have a higher proportion of 4 and 5 rated comments than average, if anything. Most of them are critical of Wikipedia's editorial realities. FWIW, I always browse interesting threads at -1 to look for good stuff to mod up and very rarely use negative mods.
Yeah, I tried the linked proof of concept on the RELEASED version of Windows 7 (the site only references beta and RC versions), and it didn't work. Either it prompted, or it failed to acquire admin or high integrity rights. I notice the site hasn't been updated for build 7600 (the RTM version), even though it's been available for some time. Even if MS patched the specific thing the proof of concept was using but failed to fix the underlying problem, they still need to release an updated version to be taken seriously. The fact that pre-release versions of Windows 7 were incomplete is hardly surprising.
RootkitRevealer comes to mind. It compares filesystem and other system database binaries raw on disk to what's returned from system calls. No known rootkits are sophisticated enough to return fake filesystem structures from raw reads to match the filtering they do.
This line of argument boils down to an implication that something exists despite claims to the contrary, just because someone isn't looking for it in a certain way. There's no reason to think that certain way of looking is exhaustive or that conditions would make that thing likely to exist in the first place. How do you know that the Russian Mafia doesn't have your phones tapped without doing a daily bug sweep? Magical ninja bug detection powers, surely.
Since Windows NT 3.1 (in 1993) it's been possible to lock a normal User down pretty tightly. Normal users can't infect the underlying system. It takes membership in the Administrator's group or certain privileges to do so.
Can you name a specific deficiency in system design that allows a normal user in any NT derived version of Windows to infect the system or other user accounts?
The reason that some games don't run properly as a normal user is because they are badly written or want to install kernel DRM/copy protection drivers. Games have always had access to the resources they would legitimately need to run.
It also offloads the graphics into faster dedicated memory and composets each window seporatly meaning crashes do not cause screen corruption.
Display drivers have always been allowed to store device associated bitmaps in video memory, and draw on them directly. However, you are right that the DWM model in Vista is better. It matches modern hardware much better than the old GDI model.
The new RDP uses far less bandwidth and allows the sending of documents to a printer using a generic driver so that each printer does not need to be installed on both sides. It also supports transport over SSL inside the base program which pipes it easily over the web. It can serve up individual applications and composite them with the other local windows. It also has full support for multiple moniters and video streaming which may be eye candy but is useful.
I thought the single window support was only in the server editions. I wasn't aware of the other features; those do sound quite useful.
BS, XP is shit at wireless. It does connect, if you get everything right and there are no adverse conditions. Enter the key wrong and it will still say it is connected but won't allow net access, it takes a minute or so to figure out it is not connected! The automatic connection method and wireless polling is also inferior in comparison. It also plays its connected but not connected games sometimes when you are using the right keys (observed in Multiple machines and environments).
I know anecdote wars are never very helpful, and I don't know what I have configured differently than you, but XP Wireless support has always just worked for me, at least post SP2 (when I've used it the most).
Using the GPU also means that it is simply a case of switching which pre rendered surface (window) is on top which is much quicker than going through GDI+ where only visible bits windows were rendered as a part of the whole screen. This meant that every move or refresh meant a whole in CPU screen re-render ad a crashed window could corrupt the screen.
Not exactly sure what you're trying to say here. When a window in the XPDDM is redrawn (due to a WM_PAINT message being received), the request is only for the changed/newly visible section. Subsequent drawing to this area and the window area is clipped by region by GDI, which prevents anything outside the changed area inside the window from being painted on. XP and Vista/7 do have a mode where they will display the last image of an unresponsive window, greyed instead of ignoring paint commands (leaving a hall of mirrors effect). Many programs were already caching their window bitmaps privately, simply blitting to WM_PAINT request areas. For compatibility, Vista and 7 still have to send messages like WM_ERASEBKGND and WM_PAINT to applications in many cases, like having the window get focus or when moving partially off screen.
There is a little more power mgmt stuff, but I wouldn't call it "much better".
GPU acceleration of the GUI
Windows NT has always supported GPU acceleration of the GUI through the display driver. The DWM just uses it differently, mostly for 3d effects and caching window contents.
DLL seperation
What does this mean? DLLs have always been mapped COW in processes, and SXS was introduced in XP.
vastly better RDP
You can use the fancy aero and desktop composition effects in RDP6, in Vista, plus support for more device redirection. This is nice, but mainly eye candy. Not a vast improvement. There isn't much substantive that you can do with RDP 6.1 that you couldn't in 5.1. Or NT4 TSE for that matter.
vastly improved central managment and deployment features for businesses
Group policy, with MSI installation, net boot installation, etc. existed in their current form since Windows 2000. There have been improvements, but no vast revolutions.
Easy 64 bit usage with drivers
XP had AMD64 support first (albeit with the WS2003 code base). The drivers are finally catching up. This is mainly the job of IHVs, not Microsoft. The drivers that Microsoft traditionally provides (most of them, really) were ready in XP64.
Faster installs
Yes, Vista now uses an image based install that supposed to be much faster.
Better power managment and usage of hardware suspend
2000 fully supported ACPI power modes. There have been minor refinements since then, but noting major.
better usage of memory (cacheing for very noticible speed gains)
SuperFetch (new in Vista) does pre-emptively fill unused memory with things that were paged out or the OS otherwise thinks you may use. To support this, the kernel now has 8 memory priorities, which help a lot in determining what should go first when memory gets tight.
Media center!
XP had MCE first.
transparent Bitlocker hard drive encryption (in pro and ultimate) with TPM
Note that per-file encryption has been supported since 2000.
program execution isolation that redirects reg and file system calls to safe locations
There have been some redirection shims since XP at least.
epiclly better wireless support
Epically? It certainly takes more clicks to get into the adapter list control panel. There are automatic locations in Vista that automatically config your firewall and such, but XP works fine if you just want to connect to the network.
support for propper GUI scaleing on high DPI LCDs
It's better, but there's still a lot of apps that break
Automatic driver retrival for most hardware right of Windows update without searching
XP will offer to search for drivers for unknown hardware, and include driver updates in Windows Update.
Faster boot times and UI responce on semi-decent hardware (compared to XP)
XP has prefetching and a lot less to load than Vista or "7". Why would the UI responsiveness be any better?
Windows 7 does have improvements, don't get me wrong I'll probably upgrade to it, but it's not making a major advance in every area. XP still does most of what 7 and Vista do, and using less resources. Besides, Vista was the major version change to 6.0.
Actually, there is a port of Office 97 to Alpha for NT3.51 and NT4. This site is dedicated to NT on Alpha and mentions some compat issues between running native Office and emulated x86 office.
Actually, there are two parts to a video driver on Windows NT, in all versions up to 5.2. In the "Windows 2000 Display Model" (the same one used in NT4), the vendor supplies a display driver, and a miniport driver.
The miniport handles things like resource allocation, memory mapping, handle interrupts, etc. This has always been in kernel mode, because it has to talk to the hardware.
The display driver is for high level drawing and rendering commands. It provides accelerated interfaces for GDI, DirectDraw and Direct3d. This, along with the Win32 windowing and graphics servers (left side of original diagram), used to live in user mode int NT3.x inside of csrss.exe with winsrv.dll. CSR still contains many functions that were never moved into kernel mode in win32k.sys.
Performance was one reason to move the display driver and winsrv into kernel mode, but I guess the biggest reason was to simplify the interface between the Win32 server and user mode clients by eliminating all the IPC marshaling. Win32k can now just reach into the client process's memory, same pointers and everything, instead of packing things into shared memory or an LPC messages.
Vista's new display model is more complex, but for the most part has a user mode display driver again.
The 6581 SID chip, which produces sound on the C64 is not programmable. The 6510 CPU has to spoon feed it commands to produce a song.
.MID files and windows metafles are a sequence of commands with parameters and (for MIDIs) timings that describe content. These commands are a high level description of the content. A generic player is capable of interpreting these instructions to render output. The C64 never had a common format like that for music. Instead, each song is a unique program for the 6510 CPU dedicated to a single song that outputs through the SID chip. Instead of describing notes directly, it has 6510 machine code instructions for loading registers, doing arithmetic, storing to memory, controlling hardware, etc. just like it was a real computer. These are usually created by excising the music portion of a larger program to make it a standalone program that just plays a song with no input. To play a song, an emulator for the 6510, 6581, memory, ROM and enough other hardware is required to let the sound program execute like it would on a real 64, controlling emulated the SID chip the same way.
This format is popular because the vast majority of original music was already in program format, and the machine code programs are much shorter than a literal description of the program's SID output.
I agree that Apple should be able to verify that full emulator is safe to execute arbitrary code that can't escape, but as other posters have noted, this may not be Apple's only concern.
Slashdot Mirror
Actually, most artificial sweeteners are much sweeter than glucose, so only a tiny quantity is needed. Sucralose for example is 600 times sweeter than sugar. Wikipedia has a nice table on the subject.
I'm not sure what "strange" is supposed to mean. There are many thousands of different chemicals present in organic foods. Many sugar substitutes are chemicals that were discovered in food plants in the first place.
If you're referring to WinRT, it's just another facade over Win32 (like .NET is, not that .NET is going anywhere) that is leaking ugly Win32 compatibility warts like MAX_PATH. The API layer beneath Win32, the native kernel syscall API, does not have have that restriction. FYI, WinRT uses COM to define WinRT, so that's not going anywhere either. If they're building their shiny new API on top of a different existing middle layer (Win32), I don't see it becoming independent or a split with the past.
I don't agree that OSX has better keyboard shortcuts than Windows. There are several things that have no default key or can't be done with the keyboard alone on OSX (except possibly with 3rd party software) For example:
Most of those have been around since Windows 3 or Windows 95 for the ones using the menu or Windows keys.
I don't actually use "shut down" or "restart" that often, so I hardly need a shortcut key for them, but a sequence that has worked since Windows 95 is WINKEY,ESC,ALT+F4 and then you have a listbox of options you can type into to select an option. Press Enter to perform the selected operation.
Both OSes have common conventions as well as guidelines produced by Apple and Microsoft. Different ISVs and apps follow those to different degrees, but there are still differences in convention. In particular, you can hit ALT in Windows to access the menu bar, each menu and menu item will have an underlined shortcut key. Dialog boxes also have ALT+ shortcuts by doing the same thing, and you can click the default button with Enter and the cancel button with Esc. Even ribbons have key sequences for every option.
The Nokia N900's OS, Maemo 5, is based on Debian and uses apt as its package manager. You can add http://repository.maemo.org/extras/ and related repositories right in the application manager UI (which is just a fancy interface for apt). The OS updates can even be done with apt-get dist-upgrade. You can even install a chrooted real Debian environment and pull random packages from the Debian repositories. And yes, pulling stuff off of apt-get is beautiful.
I didn't write the original post. I chimed in to say that you don't actually have to specify the threads and details of communication with GHC's parallelization extensions.
There is no general purpose programming environment that I know of that completely automates parallel execution. Also, with ANY programming environment, you can make a very inefficient program if you do things unwisely. For that matter, some programming environments or styles are very different and it takes rewriting to adapt existing code properly.
It's all about how easy and effectively the tools make it to do what you want. I think that GHC is among the leaders in concepts for parallel programming. The actual runtime performance is pretty good too, especially if you are willing to put some work into it.
With DPH, I am under the impression (I've used it very little so far, so maybe I'm wrong) that you use the parallel arrays pervasively within the program (any place a strict finite list would do) and the compiler will do most of the work in determining when parallel execution is worth it. Also, Erlang's recommend style of many small processes scales very easily; the runtime will decide when to call through and when to allocate those processes to separate threads. These aren't quite automatic, but it's a LOT closer than the traditional thread & semaphore model.
There are two approaches to using multiple cores in GHC:
Concurrency; which ranges from explicitly created threads (either OS threads or lightweight runtime scheduled threads or some combination) that communicate through channels or locked variables or another traditional method, to STM.
The other is parallelism. Whereas the concurrency methods all use monads to sequence and control operations and produce code that looks more like that of an imperative language, parallelism is done entirely in pure functional code. The short description of pure functional is that all data is immutable. This is very useful for parallel execution because it greatly simplifies evaluation dependencies. You don't have to worry about modifying things in the right order or change conflicts because nothing is allowed to be mutated in the first place. This enables non-strict evaluation, which means that the various values in a program (even those nested in data structures) can be evaluated at any time during program execution, and in any order (as long as they are evaluated by the time they're needed). Parallel approaches include:
In short, none of Haskell's methods of parallelization require you to be aware of threads or synchronization.
Windows NT 3.1 actually introduced Win32 first in 1993, with limited user accounts, profiles and the registry (which was the standard location for configuration). The documentation for Windows 95 marked a lot of Win32 APIs as not available, but it still specified that all application configuration should go into separate user and machine registry hives depending on the scope of the setting. Microsoft published guidelines and made them a requirement for getting the Windows 95 logo, but Microsoft has never had the power to force ISVs to do things a certain way. One choice that didn't help was that Win95 didn't implement any security to keep the OS small and simple, which hid a lot of application design problems down the road.
There are a lot of programs that have problems on newer Windows OSes that were written for earlier versions, but examples of applications that have problems even though they followed the guidelines for the OS version they were written for are extremely rare.
The function you're looking for is VirtualLock. You may also look into increasing the process's minimum working set with SetProcessWorkingSetSize. This requires SeIncreaseBasePriorityPrivilege.
A process that is scanning through a file is supposed to use the FILE_FLAG_SEQUENTIAL_SCAN hint so that the cached pages are recycled first, but that doesn't always happen. It also doesn't help that csrss will ask the kernel to minimize a process's working set when its main window is minimized.
I don't know that it's documented in detail anywhere. The beginning priority seems to be based on the process's priority (5 for normal apparently) and is adjusted by usage heuristics and superfetch. There is a overview here. It may help to raise the priority of FF to AboveNormal if it seems like its pages are being discarded unnecessarily.
What the other posters said in reply to your other post about the OS not really knowing what memory belongs to what tab, instead having a page level view of things, is correct. When the CPU accesses a page, it sets a flag in the page descriptor that the page was accessed. The memory manager checks these flags periodically to see what pages are being used. When the MM thinks the process has too many pages, it takes away those that haven't had that flag set in a while. I guess the frequency of usage has some effect on the priority, but I'm not sure.
On Windows it doesn't necessarily mean that. Writing a page to disk != needing to read it back from disk later.
Each process has a working set. Pages in the working set are mapped actively into the process's VM with page tables. The memory manager aggressively trims these pages from the working set and puts them into standby memory. A page in standby is not mapped for reading (and more importantly for writing) anywhere in the system. Part of putting the page into standby involves writing a copy to disk. This will show up as a page written.
From standby, the page can be used one of two ways:
The nice thing about this model is that disk activity isn't needed to either reuse pages or bring them back at the time of the demand. It helps avoid the ugly condition of paging one process out while paging another in at the same time, causing disk thrashing.
Since Vista, the memory manager will preemptively re load pages that have been bumped out of standby back into standby if there is free unused memory available. Also since Vista, each page of memory has a priority from 0-7 that determines which pages are preferred to keep in RAM. In all versions of NT based Windows, memory mapping is very similar to page file management and will use many of the same counters (including standby memory, transition and hard faults, pages in/out). Memory mapping is used by lots of components internally and for loading executable images and libraries. Also, file caching is logically based in many ways on memory mapping, although the counters are different in many cases.
The OS is Maemo 5 "Fremantle", which is based on Debian (and BusyBox), but some of the ways it's set up aren't fully compatible with a lot of Debian standard software. I don't think you can just add the Debian ARM repositories directly and install stuff. Packages have to be tested and sometimes modified to work natively.
However, it is popular to create a real Debian environment with chroot, which works around that problem. See Easy Debian, which is a package that does all the work in setting that up, including OpenOffice.org, GIMP, LXDE and an environment you really can apt-get install most anything from the Debian mainline into.
I've had a N900 since December. I'm very happy with it. Installed Easy Debian and OpenOffice and they work quite well. There's only so much word processing I want to do on a platform that size, but it's great for modifying office email attachments on occasion. Having a spreadsheet in my pocket is quite handy too. Stylus is recommended but not compulsory. It's still in testing and there are a few headaches, like some dialogs being too tall to properly reach the buttons at the bottom, but it's already improved a lot from previous versions and I expect it to get even better.
As for the community, the main forums don't look dead to me. Have a look at the packages they offer.
IE6 is the only browser supported where I work, you insensitive clod! (It's the latest version available for Windows 2000. Plus there are corporate web apps that only work properly with IE6.)
T-Mobile Even More Plus
There is a keywords field under summary (since Win2k actually). The volume will need to be NTFS, since those extra properties are stored in alternate data streams. I believe that it's indexed. I think you use the "tag:" prefix to find them.
It could be that the post just before that one by Nwallins (1059978) on 2009.11.25 13:41 (#30228784) makes the same mention of http://en.wikipedia.org/wiki/Wikipedia:Be_bold. I wouldn't have marked either as redundant though because the other was first and the second one has more material.
/.'s moderation system was too far gone or biased on this topic. This story seems to have a higher proportion of 4 and 5 rated comments than average, if anything. Most of them are critical of Wikipedia's editorial realities. FWIW, I always browse interesting threads at -1 to look for good stuff to mod up and very rarely use negative mods.
I also wouldn't say that
Yeah, I tried the linked proof of concept on the RELEASED version of Windows 7 (the site only references beta and RC versions), and it didn't work. Either it prompted, or it failed to acquire admin or high integrity rights. I notice the site hasn't been updated for build 7600 (the RTM version), even though it's been available for some time. Even if MS patched the specific thing the proof of concept was using but failed to fix the underlying problem, they still need to release an updated version to be taken seriously. The fact that pre-release versions of Windows 7 were incomplete is hardly surprising.
RootkitRevealer comes to mind. It compares filesystem and other system database binaries raw on disk to what's returned from system calls. No known rootkits are sophisticated enough to return fake filesystem structures from raw reads to match the filtering they do.
This line of argument boils down to an implication that something exists despite claims to the contrary, just because someone isn't looking for it in a certain way. There's no reason to think that certain way of looking is exhaustive or that conditions would make that thing likely to exist in the first place. How do you know that the Russian Mafia doesn't have your phones tapped without doing a daily bug sweep? Magical ninja bug detection powers, surely.
Here is a collection of references. See also Readers Write: How Microsoft got Windows NT, Everything2: The similarities between VMS and Windows NT and Windows NT and VMS: The Rest of the Story (use googlebot useragent to view full story).
DEC did sue Microsoft, but they settled for royalties.
Since Windows NT 3.1 (in 1993) it's been possible to lock a normal User down pretty tightly. Normal users can't infect the underlying system. It takes membership in the Administrator's group or certain privileges to do so.
Can you name a specific deficiency in system design that allows a normal user in any NT derived version of Windows to infect the system or other user accounts?
The reason that some games don't run properly as a normal user is because they are badly written or want to install kernel DRM/copy protection drivers. Games have always had access to the resources they would legitimately need to run.
It also offloads the graphics into faster dedicated memory and composets each window seporatly meaning crashes do not cause screen corruption.
Display drivers have always been allowed to store device associated bitmaps in video memory, and draw on them directly. However, you are right that the DWM model in Vista is better. It matches modern hardware much better than the old GDI model.
The new RDP uses far less bandwidth and allows the sending of documents to a printer using a generic driver so that each printer does not need to be installed on both sides. It also supports transport over SSL inside the base program which pipes it easily over the web. It can serve up individual applications and composite them with the other local windows. It also has full support for multiple moniters and video streaming which may be eye candy but is useful.
I thought the single window support was only in the server editions. I wasn't aware of the other features; those do sound quite useful.
BS, XP is shit at wireless. It does connect, if you get everything right and there are no adverse conditions. Enter the key wrong and it will still say it is connected but won't allow net access, it takes a minute or so to figure out it is not connected! The automatic connection method and wireless polling is also inferior in comparison. It also plays its connected but not connected games sometimes when you are using the right keys (observed in Multiple machines and environments).
I know anecdote wars are never very helpful, and I don't know what I have configured differently than you, but XP Wireless support has always just worked for me, at least post SP2 (when I've used it the most).
Using the GPU also means that it is simply a case of switching which pre rendered surface (window) is on top which is much quicker than going through GDI+ where only visible bits windows were rendered as a part of the whole screen. This meant that every move or refresh meant a whole in CPU screen re-render ad a crashed window could corrupt the screen.
Not exactly sure what you're trying to say here. When a window in the XPDDM is redrawn (due to a WM_PAINT message being received), the request is only for the changed/newly visible section. Subsequent drawing to this area and the window area is clipped by region by GDI, which prevents anything outside the changed area inside the window from being painted on. XP and Vista/7 do have a mode where they will display the last image of an unresponsive window, greyed instead of ignoring paint commands (leaving a hall of mirrors effect). Many programs were already caching their window bitmaps privately, simply blitting to WM_PAINT request areas. For compatibility, Vista and 7 still have to send messages like WM_ERASEBKGND and WM_PAINT to applications in many cases, like having the window get focus or when moving partially off screen.
Much better use of multicore CPUs
There is a little more power mgmt stuff, but I wouldn't call it "much better".
GPU acceleration of the GUI
Windows NT has always supported GPU acceleration of the GUI through the display driver. The DWM just uses it differently, mostly for 3d effects and caching window contents.
DLL seperation
What does this mean? DLLs have always been mapped COW in processes, and SXS was introduced in XP.
vastly better RDP
You can use the fancy aero and desktop composition effects in RDP6, in Vista, plus support for more device redirection. This is nice, but mainly eye candy. Not a vast improvement. There isn't much substantive that you can do with RDP 6.1 that you couldn't in 5.1. Or NT4 TSE for that matter.
vastly improved central managment and deployment features for businesses
Group policy, with MSI installation, net boot installation, etc. existed in their current form since Windows 2000. There have been improvements, but no vast revolutions.
Easy 64 bit usage with drivers
XP had AMD64 support first (albeit with the WS2003 code base). The drivers are finally catching up. This is mainly the job of IHVs, not Microsoft. The drivers that Microsoft traditionally provides (most of them, really) were ready in XP64.
Faster installs
Yes, Vista now uses an image based install that supposed to be much faster.
Better power managment and usage of hardware suspend
2000 fully supported ACPI power modes. There have been minor refinements since then, but noting major.
better usage of memory (cacheing for very noticible speed gains)
SuperFetch (new in Vista) does pre-emptively fill unused memory with things that were paged out or the OS otherwise thinks you may use. To support this, the kernel now has 8 memory priorities, which help a lot in determining what should go first when memory gets tight.
Media center!
XP had MCE first.
transparent Bitlocker hard drive encryption (in pro and ultimate) with TPM
Note that per-file encryption has been supported since 2000.
program execution isolation that redirects reg and file system calls to safe locations
There have been some redirection shims since XP at least.
epiclly better wireless support
Epically? It certainly takes more clicks to get into the adapter list control panel. There are automatic locations in Vista that automatically config your firewall and such, but XP works fine if you just want to connect to the network.
support for propper GUI scaleing on high DPI LCDs
It's better, but there's still a lot of apps that break
Automatic driver retrival for most hardware right of Windows update without searching
XP will offer to search for drivers for unknown hardware, and include driver updates in Windows Update.
Faster boot times and UI responce on semi-decent hardware (compared to XP)
XP has prefetching and a lot less to load than Vista or "7". Why would the UI responsiveness be any better?
Windows 7 does have improvements, don't get me wrong I'll probably upgrade to it, but it's not making a major advance in every area. XP still does most of what 7 and Vista do, and using less resources. Besides, Vista was the major version change to 6.0.
Actually, there is a port of Office 97 to Alpha for NT3.51 and NT4. This site is dedicated to NT on Alpha and mentions some compat issues between running native Office and emulated x86 office.
Actually, there are two parts to a video driver on Windows NT, in all versions up to 5.2. In the "Windows 2000 Display Model" (the same one used in NT4), the vendor supplies a display driver, and a miniport driver.
The miniport handles things like resource allocation, memory mapping, handle interrupts, etc. This has always been in kernel mode, because it has to talk to the hardware.
The display driver is for high level drawing and rendering commands. It provides accelerated interfaces for GDI, DirectDraw and Direct3d. This, along with the Win32 windowing and graphics servers (left side of original diagram), used to live in user mode int NT3.x inside of csrss.exe with winsrv.dll. CSR still contains many functions that were never moved into kernel mode in win32k.sys.
Performance was one reason to move the display driver and winsrv into kernel mode, but I guess the biggest reason was to simplify the interface between the Win32 server and user mode clients by eliminating all the IPC marshaling. Win32k can now just reach into the client process's memory, same pointers and everything, instead of packing things into shared memory or an LPC messages.
Vista's new display model is more complex, but for the most part has a user mode display driver again.
It's called price discrimination. More editions help Microsoft soak up more consumer surplus.
The 6581 SID chip, which produces sound on the C64 is not programmable. The 6510 CPU has to spoon feed it commands to produce a song.
.MID files and windows metafles are a sequence of commands with parameters and (for MIDIs) timings that describe content. These commands are a high level description of the content. A generic player is capable of interpreting these instructions to render output. The C64 never had a common format like that for music. Instead, each song is a unique program for the 6510 CPU dedicated to a single song that outputs through the SID chip. Instead of describing notes directly, it has 6510 machine code instructions for loading registers, doing arithmetic, storing to memory, controlling hardware, etc. just like it was a real computer. These are usually created by excising the music portion of a larger program to make it a standalone program that just plays a song with no input. To play a song, an emulator for the 6510, 6581, memory, ROM and enough other hardware is required to let the sound program execute like it would on a real 64, controlling emulated the SID chip the same way.
This format is popular because the vast majority of original music was already in program format, and the machine code programs are much shorter than a literal description of the program's SID output.
See MOS Technology SID - Software emulation
I agree that Apple should be able to verify that full emulator is safe to execute arbitrary code that can't escape, but as other posters have noted, this may not be Apple's only concern.