PC Sympathy - Your Source for PC News And Technical Support

What’s the difference? Well, at the very core of them, not much. When you see talk of Windows 98/ME being more stable than Windows 2000 or XP, don’t buy into it. Not because 98SE isn’t one of Microsoft’s better efforts, but because of the disaster of an OS architecture that it still relies upon. By the end of the road, Windows 9x had become such a massive quagmire of heaped on patches and features that it ultimately led to Windows ME… arguably the worst operating system release to ever come from Microsoft. I’d rather use Window 95 than ME.

Windows NT started as a joint venture between IBM and Microsoft you might have heard of… OS/2. A long-running spat between the two eventually forced a split, and each walked away with a copy of the code and the intention to take it in their own direction. The intent was to design a completely modular operating system whereby entire portions of the system could be replaced at will by third parties or by Microsoft in order to support varying hardware platforms, security models or interface elements. Memory management and process separation were paramount design goals. This is the single most important factor in system and application stability because one failed driver or program should not be capable of taking down the entire operating system.

Shooting themselves in the foot, enter the magical Blue Screen of Death (BSOD). Instead, a single driver or application can cause the operating system to detect the failure, but not understand how to handle the error. The result is a wealth of dump information that is still of little help to this day. Better than a generic VxD error that can be caused by something totally unrelated, but this trend of STOP error codes having many different meanings isn’t much better, and early versions of NT would gak on even the most trivial of error conditions. The upside is that somebody on the planet can take that information and turn it into something useful… just not anyone that you or I can easily reach. But I digress.

When NT 3.1 was released, it brought Windows to the server for real… well, sort of. Narrow hardware support, half-hearted feature sets and stability nightmares galore labeled 3.1 as a retail Beta release, but if all of the ducks where lined up in a neat little row, it ran quite well. Then came 3.5, which improved things quite a bit, but still left a sour taste in the mouths of customers Microsoft was trying to win over from Novell and Banyan, mainly due to a complete lack of maturity of features and little in the way of real interoperability with existing networks.

Windows NT 3.51 was when this new entrant really made its debut. It wasn’t great, but it was good enough to put into production for certain things. File and print serving were adequate, and it made for an acceptable SQL and Exchange platform. The workstation version was rough, however. Compatibility was difficult, at best. 16-bit Windows application support made DOS look like a step forward. This would get better, though.

NT 4.0 is generally considered to be when the Windows NT core came into its own, and I would have to agree. I would use NT 4.0 whenever possible, dual-booting with Windows 95/98 only when absolutely necessary because of the relative stability that NT offered and the more advanced security and file system features included in the OS. Finally, a workstation OS that would let me take full advantage of extra RAM and multiple CPUs, while still letting me limp along with some games and “legacy” applications if tweaked properly. I was working for an insurance company at the time of the NT 4.0 release and we decided to make NT 4.0 Workstation the standard for desktops company-wide. I considered this to be a relative success, having migrated and rolled out some 800+ PCs based on NT 4.0 and aside from a funky token ring card driver, everything ran quite well. I truly liked NT 4.0, but was eagerly awaiting improvements in Windows 2000.

As hardware advanced, and the vision of ditching the 9x code base creeped closer, Microsoft had to do something about the constant install-and-reboot issues, power management, networking services and multimedia support. These were the highlights of Windows 2000, and they couldn’t come soon enough. Driver development is probably the one thing that held Windows 2000 back from replacing Windows 9x outright rather than waiting for Windows XP. For whatever reason, manufacturers just didn’t get the hint. They still saw that the majority were using 9x, so why play to that geek crowd that just likes to be different? They eventually learned the hard way, but at the expense of many frustrated customers that wanted what Windows 2000 could give them otherwise.

Now we’re at Windows XP. Still based on the very beginnings of Windows NT, though obviously quite a bit different these days. No longer is Microsoft bent on the modular rip-and-replace design of years past. Some of that capability is still around, but mainly used in server systems that require specific Hardware Abstraction Layer components in order for the OS to speak to the hardware properly. Aside from that, you don’t see many entire shell replacements, network authentication modules or other allowances for non-Microsoft modifications (e.g. entire antitrust debacle).

The overall stability of Windows XP has been quite good. Even fewer reboots are required today, though I’m still waiting for the day when all but kernel-level changes lack the requirement of a system restart. Reboots are annoying. Hot-docking, suspend, hibernate and other dynamic features within Windows XP are admittedly better, but still problematic. And don’t even get me started on XP Service Pack 1. I’m still avoiding it like the plague, in case you’re wondering.

So, here we are in late 2002, with the next major version of Windows due somewhere around 2005-2006 and that doesn’t really bother me. Windows ME showed what can happen if things are rushed in an effort to have another source of revenue. There is talk of an interim release of some sort, but the details are sketchy at this point. Microsoft is moving in the right direction, having finally shoved all operating systems over to the NT code base. It’s far more stable, efficient, secure and usable than 98 or ME ever were. Gamers still have a few gripes, but those should be thrown at the game developers for not waking up long ago. DirectX is DirectX, and if a developer isn’t following along with what Microsoft is doing, then they will fall behind the times. I play a few games under XP and have few problems. In fact, it’s better in most cases because of how memory and system resources are utilized.

At the end of this little lesson in history and perspective, should you upgrade to Windows 2000 or XP? I still say it depends. If all you do is surf, read email and watch a video or two, 98 or ME will still suffice. Should you could yourself to be dependant on your computer for much more, I would say that you should seriously consider the move. However, let me qualify that with a plea for how you go about it. Please, please, do not “upgrade”. Do a clean installation. It’s worth every bit of time and effort to wipe the slate clean rather than trying to move to an entirely different architecture while preserving your settings and applications from the past several years. Things are bound to go wrong, no matter how much time and effort Microsoft puts into smooth transitions. They can never account for every nasty application, suspect driver and legacy device among the billions of combinations. Start over. You’ll be a much happier camper. I’ve been using NT-based operating systems since before NT was NT, and ask that you trust me on this one. You would still qualify for the upgrade version of the OS, but this does not require you to perform an actual upgrade of your existing installation. You simply have to have the media from your existing OS handy for verification that you do have an upgradeable product.

Also, don’t even think about Windows XP with less than 256MB of RAM. I know the book answer is 128MB, but forget it. You’re kidding yourself. XP is a pig, and the more RAM you can give it, the better. I run with 512MB in my notebook, and when I get rolling, I can chew that up quite easily. Bloated code, useless services enabled by default, and a prefetch engine that loves RAM… welcome to Windows. For what it’s worth, I have the same recommendation for MacOS X. Anything less than 256MB of RAM, and it can get painful (though you can do more with 256MB under OS X than under XP). I’m afraid it’s the way of the world from here on out. Remember the days when a 1GB disk (heck, a 5MB disk) was considered huge? Today, 1GB of RAM is more common than you might think. I have 2GB in my Gateway 6400 server and plan to move to 4GB in my Dell PowerEdge 1400SC server down the road. I’d have 1GB in my notebook already if it supported such capacities.

Posted in Windows | No Comments

HTTP Error Codes

March 8, 2008 – 8:58 AM

Part of Hypertext Transfer Protocol — HTTP/1.1
RFC 2616 Fielding, et al.

10 Status Code Definitions

Each Status-Code is described below, including a description of which method(s) it can follow and any metainformation required in the response.

10.1 Informational 1xx

This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any 1xx status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client except under experimental conditions.

A client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 (Continue) status message. Unexpected 1xx status responses MAY be ignored by a user agent.

Proxies MUST forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself requested the generation of the 1xx response. (For example, if a

proxy adds a “Expect: 100-continue” field when it forwards a request, then it need not forward the corresponding 100 (Continue) response(s).)

10.1.1 100 Continue

The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed. See section 8.2.3 for detailed discussion of the use and handling of this status code.

10.1.2 101 Switching Protocols

The server understands and is willing to comply with the client’s request, via the Upgrade message header field (section 14.42), for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the response’s Upgrade header field immediately after the empty line which terminates the 101 response.

The protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.

10.2 Successful 2xx

This class of status code indicates that the client’s request was successfully received, understood, and accepted.

10.2.1 200 OK

The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:

GET an entity corresponding to the requested resource is sent in the response;

HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;

POST an entity describing or containing the result of the action;

TRACE an entity containing the request message as received by the end server.

10.2.2 201 Created

The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead.

A 201 response MAY contain an ETag response header field indicating the current value of the entity tag for the requested variant just created, see section 14.19.

10.2.3 202 Accepted

The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.

The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent’s connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request’s current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.

10.2.4 203 Non-Authoritative Information

The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. The set presented MAY be a subset or superset of the original version. For example, including local annotation information about the resource might result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only appropriate when the response would otherwise be 200 (OK).

10.2.5 204 No Content

The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.

If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent’s active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent’s active view.

The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.

10.2.6 205 Reset Content

The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action. The response MUST NOT include an entity.

10.2.7 206 Partial Content

The server has fulfilled the partial GET request for the resource. The request MUST have included a Range header field (section 14.35) indicating the desired range, and MAY have included an If-Range header field (section 14.27) to make the request conditional.

The response MUST include the following header fields:

      - Either a Content-Range header field (section 14.16) indicating
        the range included with this response, or a multipart/byteranges
        Content-Type including Content-Range fields for each part. If a
        Content-Length header field is present in the response, its
        value MUST match the actual number of OCTETs transmitted in the
        message-body.

      - Date

      - ETag and/or Content-Location, if the header would have been sent
        in a 200 response to the same request

      - Expires, Cache-Control, and/or Vary, if the field-value might
        differ from that sent in any previous response for the same
        variant

If the 206 response is the result of an If-Range request that used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the response MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.

A cache MUST NOT combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see 13.5.4.

A cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial) responses.

10.3 Redirection 3xx

This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection.

      Note: previous versions of this specification recommended a
      maximum of five redirections. Content developers should be aware
      that there might be clients that implement such a fixed
      limitation.

10.3.1 300 Multiple Choices

The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location.

Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of

the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.

If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise.

10.3.2 301 Moved Permanently

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

      Note: When automatically redirecting a POST request after
      receiving a 301 status code, some existing HTTP/1.0 user agents
      will erroneously change it into a GET request.

10.3.3 302 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

      Note: RFC 1945 and RFC 2068 specify that the client is not allowed
      to change the method on the redirected request.  However, most
      existing user agent implementations treat 302 as if it were a 303
      response, performing a GET on the Location field-value regardless
      of the original request method. The status codes 303 and 307 have
      been added for servers that wish to make unambiguously clear which
      kind of reaction is expected of the client.

10.3.4 303 See Other

The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.

The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

      Note: Many pre-HTTP/1.1 user agents do not understand the 303
      status. When interoperability with such clients is a concern, the
      302 status code may be used instead, since most user agents react
      to a 302 response as described here for 303.

10.3.5 304 Not Modified

If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.

The response MUST include the following header fields:

      - Date, unless its omission is required by section 14.18.1

If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly.

      - ETag and/or Content-Location, if the header would have been sent
        in a 200 response to the same request

      - Expires, Cache-Control, and/or Vary, if the field-value might
        differ from that sent in any previous response for the same
        variant

If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.

If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.

If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.

10.3.6 305 Use Proxy

The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers.

      Note: RFC 2068 was not clear that 305 was intended to redirect a
      single request, and to be generated by origin servers only.  Not
      observing these limitations has significant security consequences.

10.3.7 306 (Unused)

The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.

10.3.8 307 Temporary Redirect

The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI.

If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

10.4 Client Error 4xx

The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included entity to the user.

If the client is sending data, a server implementation using TCP SHOULD be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes the input connection. If the client continues sending data to the server after the close, the server’s TCP stack will send a reset packet to the client, which may erase the client’s unacknowledged input buffers before they can be read and interpreted by the HTTP application.

10.4.1 400 Bad Request

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

10.4.2 401 Unauthorized

The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in “HTTP Authentication: Basic and Digest Access Authentication” [43].

10.4.3 402 Payment Required

This code is reserved for future use.

10.4.4 403 Forbidden

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

10.4.5 404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

10.4.6 405 Method Not Allowed

The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.

10.4.7 406 Not Acceptable

The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.

Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.

      Note: HTTP/1.1 servers are allowed to return responses which are
      not acceptable according to the accept headers sent in the
      request. In some cases, this may even be preferable to sending a
      406 response. User agents are encouraged to inspect the headers of
      an incoming response to determine if it is acceptable.

If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.

10.4.8 407 Proxy Authentication Required

This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field (section 14.33) containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field (section 14.34). HTTP access authentication is explained in “HTTP Authentication: Basic and Digest Access Authentication” [43].

10.4.9 408 Request Timeout

The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.

10.4.10 409 Conflict

The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough

information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.

Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can’t complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.

10.4.11 410 Gone

The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.

The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server’s site. It is not necessary to mark all permanently unavailable resources as “gone” or to keep the mark for any length of time — that is left to the discretion of the server owner.

10.4.12 411 Length Required

The server refuses to accept the request without a defined Content- Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request message.

10.4.13 412 Precondition Failed

The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows the client to place preconditions on the current resource metainformation (header field data) and thus prevent the requested method from being applied to a resource other than the one intended.

10.4.14 413 Request Entity Too Large

The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.

If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again.

10.4.15 414 Request-URI Too Long

The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a URI “black hole” of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some servers using fixed-length buffers for reading or manipulating the Request-URI.

10.4.16 415 Unsupported Media Type

The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method.

10.4.17 416 Requested Range Not Satisfiable

A server SHOULD return a response with this status code if a request included a Range request-header field (section 14.35), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first- byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.)

When this status code is returned for a byte-range request, the response SHOULD include a Content-Range entity-header field specifying the current length of the selected resource (see section 14.16). This response MUST NOT use the multipart/byteranges content- type.

10.4.18 417 Expectation Failed

The expectation given in an Expect request-header field (see section 14.20) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server.

10.5 Server Error 5xx

Response status codes beginning with the digit “5” indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user. These response codes are applicable to any request method.

10.5.1 500 Internal Server Error

The server encountered an unexpected condition which prevented it from fulfilling the request.

10.5.2 501 Not Implemented

The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.

10.5.3 502 Bad Gateway

The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.

10.5.4 503 Service Unavailable

The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.

      Note: The existence of the 503 status code does not imply that a
      server must use it when becoming overloaded. Some servers may wish
      to simply refuse the connection.

10.5.5 504 Gateway Timeout

The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.

      Note: Note to implementors: some deployed proxies are known to
      return 400 or 500 when DNS lookups time out.

10.5.6 505 HTTP Version Not Supported

The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in section 3.1, other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server.

Posted in Coding, Internet, Networking | No Comments

VMM32.VXD

March 7, 2008 – 6:48 PM

An InfiniSource TechFile

By Roy Lehrer

Everything in this article applies to all versions of Windows 9X including the recently released Windows 98 Second Edition versions.

Rumors:

Before I go into the details of telling you how to rebuild a corrupt vmm32.vxd file, let me first say with very strong emphasis that there is no truth to the reports that Win9X does not install all required *.vxd files during installation. While it’s possible that such a bug may have existed in a very early Win98 beta release (going back to when it was called Memphis and not Win98), there is no such bug, nor has there ever been such a bug in any released version of Win95 thru Win98 Second Edition.

There are various web sites, such as http://home.tampabay.rr.com/philip1/Windows/win_bugs.htm where you can read about this non-existent bug that I think is plain hogwash. My experience says that such sites are incorrectly informing you that during Win9X installation, some required *.vxd files do not get installed and that you have to install them yourself manually, and that these “missing” files are the cause of at least some of your problems. Again I say hogwash. Some of these sites go on even further to tell you that you can check to see if any *.vxd files are missing by using Device Manager (from System Manager in the Control Panel) and using the Driver File Details tab and that if you find entries containing ‘vmm32’, there’s a good chance you need to extract and then install these files manually. Some go on to more explicitly tell you that if you see entries that look like C:\Windows\System\vmm32.vxd (configmg.vxd) that you do have to extract the *.vxd file manually from your Win98 CD cab files and put them in your \Windows\system\iosubsys directory after which the Driver File Details will show C:\Windows\System\configmg.vxd which is the correct way an entry should look.

As I just said I think this whole issue is just plain old-fashioned hogwash. Someone who doesn’t/didn’t have the slightest idea of what vmm32.vxd is or how it is used probably originated it. And as we all know, anything posted on the web spreads like wildfire and is taken to be gospel by many even if it shouldn’t. A more forgiving reason (it you want to call it that), although unlikely based on the details of what is being said, is that a person whose vmm32.vxd file got corrupted started it. But even then he/she didn’t know what they are talking about if they are saying a bug in Win9X prevents the *.vxd files from getting installed.

What is VMM32.VXD:

To try and explain why what these sites tell you is wrong, you need to know what vmm32.vxd is. Vmm32.vxd is a monolithic driver file made up of a number of various *.vxd files. It is a W4 format archive using the MRCI compression of Drivespace. However, to keep things simple, you can think of it as a archive of different *.vxd files combined into one library file that can loaded as one file but that the individual files within it can be used as if they were individually loaded. Basically vmm32.vxd just contains a collection of different *.vxd files your system needs for startup, each file is stripped of the headers that are required if that same file was loaded separately. Between the stripped headers and the compression used in vmm32.vxd it is considerably smaller that all the individual files, contributing to its faster load time. One of the most important things about vmm32.vxd is that the actual *.vxd files it contains is determined for each system on an individual basis during the original Win9X installation to that system, and that the vmm32.vxd file on one system may be quite different than the one on another system. So if your file gets corrupted you can’t just copy the one from you buddy’s system and expect it to work unless his system was 100% identical to yours at the time you each installed the exact same version of Win9X. You also have to know that the vmm32.vxd file that can be extracted from the Win9X cab files is just a skeleton file that is used to build upon during the Win9X installation process, so just extracting it will not restore a corrupted vmm32.vxd file. If you did extract vmm32.vxd from your cab files and overwrote the one in your \Windows\system directory with it, the result would be a system that you could not start Win9X on.

So to reiterate, the files these web sites claim are missing are not missing, they are actually part of vmm32.vxd, which is why you normally will not find them as individual files on your system. The fact that users could not find these files on their system may have led to the acceptance that they Win9X did not install them. By the way, the Device Manager, Driver File Details type of entry that reads something like C:\Windows\System\vmm32.vxd (configmg.vxd) is absolutely correct. It is telling you that the driver being used is configmg.vxd but that is it loaded from vmm32.vxd instead of as a stand-alone file. If it were loaded from a stand-alone file then the entry would read C:\Windows\System\configmg.vxd.

Now there may come a time, when one of the *.vxd files built into vmm32.vxd needs to be updated, and Win9x provides a very simple means for this. Each system has a \Windows\system\vmm32 directory. Any *.vxd file in this directory will be automatically loaded and used during Win9X startup, instead of the one in the vmm32.vxd file if it exists in both places. In other words files in this directory take precedence over same files within vmm32.vxd. So when these web sites have you put the individual files in this directory all they are doing is putting a copy of the same code that is already within vmm32.vxd into this directory as stand alone files which will actually cause Win9X to take longer to load. Microsoft says that Extracting system files that are rolled into VMM32.VxD will not increase system performance, once you are started, there will be no difference. The reason for bundling VxD’s into VMM32 was to improve system boot time.

To see a list of all the files included in your vmm32.vxd file use regedit.exe and go to the key HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ VMM32Files. All files listed in the right side of the display are within your system’s personalized copy of vmm32.vxd.

As you may have gathered, since the VMM32.VXD in use on your system was custom created for you system based on its requirements, it is one file that you cannot simply extract from your Win98 cabs files if it should become corrupt or if it accidentally gets erased from your system. So RIGHT NOW is a good time to stop reading and make a backup copy of it in case you ever need it.

Why would you ever need to rebuild:

I can only think of two reasons for needing to re-build your vmm32.vxd file. The first is because your current copy is no longer usable or was deleted. So as I said just above, back it up now and you don’t have to worry about this.

The other reason may be that at some point in time due to updates, etc, you may have a large number of updated *.vxd files in your \Windows\system\vmm32 directory and would like to return to having the files load via the faster loading vmm32.vxd. Personally I don’t think that the load time difference is worth the effort but since vmm32.vxd can be rebuilt I will tell you how.

Procedure:

Notes:

Some of the steps only tell you what needs to be done and not how to do it. If you don’t know how to do it, then I suggest that you should re-consider attempting this procedure.
In this archive are samples of what the 2 batch files you are going to create should look like. As written they may not be appropriate for your system, so please follow the steps below to create batch files for your system, and use the samples only as a guide to what your completed batch files should look like.
The entire procedure can be run from within the Win9X GUI, there is no need to start in Real Mode DOS, as is the case with the earlier version of this procedure.
Note that in my examples in some of the steps, I only show 3 entries for file lists that will be much larger (probably 40 or more lines). Also for these batch files you will be creating case does not matter.

First you must know what files are in your current vmm32.vxd file. You can get a list from the registry at HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ VMM32Files. Since the list is rather long, and because this procedure involves creating a batch file using this list of file names, the easiest thing to do is export this key to VMM32.REG
Open VMM32.REG in any editor that you want. An editor with Search and Replace (abbreviated as S&R in this procedure) capability is best (thus NotePad will not do, but WordPad will). The steps in this procedure are written to take advantage of S&R. The editor you use must allow you to save the results to an ASCII text file.
Delete the first few lines so that you are left with a list that looks something like the following:
Save what you have so far as WININIT.INI, which we use later in this procedure.
Now continuing editing VMM32.REG and using S&R enter “=hex:00 (Note the leading quote mark in this text) as the search string and leave the replace text blank and then do a Replace All. You should now have a list that looks something like:
Now replace all occurrences of “ (a single quote mark) with one of the following text strings:
Now ADD the following 5 lines to the TOP of the file:
The C: in the second line must be changed if you have Win9X installed on a different drive. You need to change the two CD commands accordingly if \Windows is not your base Win9X directory. These commands are necessary to ensure that the files get extracted from the cab files to the appropriate locations on your HD.
Now ADD lines similar to what’s below to the END of the file. The purpose of these lines is just to give you some sort of an on-screen message when GETVXD.BAT finishes so that you will know it, and also know that it is OK to close the Dos Window that will be left open:
Now compare your list of file of files to be extracted to those files that currently exist in your \Windows\system\vmm32 directory. If any files in your list already exist in this directory chances are that they are newer versions than what is on your CD. It is up to you to determine this. If you determine that the version of a file in your \Windows\system\vmm32 directory is newer than what is in your cab files, then Delete that entry from the list because we don’t want to overwrite a newer version already existing in the directory with an older one that will be extracted from your cab files.
Save your work as GETVXD.BAT
Load the WININIT.INI saved in step 4 into your editor.
Using S&R enter “=hex:00 (Note the leading quote mark in this text) as the search text and for the replacement text enter =c:\windows\system\vmm32.vxd (adjust the drive\path if necessary) and then perform a Replace All. You should now have a list that looks something like:
Using S&R enter “ (a single quote mark) as the search text and c:\windows\system\vmm32\ (adjust drive\path if necessary) as the replacement text and perform a Replace All. You should now have a list that looks something like:
At the TOP of the file add a section header of [SetupOptions] and under it Combine=1, Under this add another section header of [CombineVxDs]. Your file should now be similar to:
Once you have your file looking like the above example save it keeping the name WININIT.INI
Move WININIT.INI and GETVXD.BAT from wherever you saved them with your editor to your \Windows directory
Although not required for the rest of the procedure to work, I strongly suggest that you backup any files that already exist in your \Windows\system\vmm32 directory as well as your current vmm32.vxd file and your current registry. How you backup these files is up to you.
In the Start > Run dialog enter GETVXD and click on OK to start the batch file which should log you on to the HD that contains Win9X, change to the appropriate directories and extract all file to these directories, automatically overwriting any files that exist with the same filename. Depending on your system speed this batch file may take a while to execute due to the simple way it was written which caused only one file to be extracted from the cabs at a time. I don’t think you will be using this batch file often enough to worry about combining filenames on an extract command line to save a little time by extracting multiple files at a time.
Restart Win9X and during the startup process, WININIT.INI will be processed. While wininit.ini is being processed you will get a Please wait while Setup updates… message on your screen, as the new vmm32.vxd file is created from the individual files in the \Windows\system\vmm32 directory. During the process, all files combined into vmm32.vxd will be deleted from the \Windows\system\vmm32 directory leaving only those that do not belong in vmm32.vxd (were not listed in your wininit.ini file) which should have been there before starting this procedure.

That’s it, you should have re-built your vmm32.vxd file. If everything is working, BACKUP your new vmm32.vxd file now, so if anything happens to it you don’t have to repeat this procedure.
What if I can’t start Win9X or have other problems:

Recovery is quite simple if you followed my suggestion to make backups. All you should have to do is replace \Windows\system\vmm32.vxd and delete any files in the \Windows\system\vmm32 directory that were not there when you started. If you made backup, then you should be able to delete everything in this directory and just restore it from your backup. The procedure causes NO changes, additions or deletions to your registry, so you should not need to restore it. However if you can’t start Win9X, then you did something wrong and since regedit.exe was used you may have accidentally corrupted your registry and if this is the case you may have to restore it from you backup. So you can either do it now or wait and see if it is required after you attempt to restart Win9X after restoring your original vmm32.vxd and \Windows\system\vmm32 files.

Microsoft Knowledge Base Articles

Here are some Microsoft Knowledge Base Articles dealing with VMM32 errors:

Windows 95/98 Boots Directly to “Shut Down” Screen – Q141898
Missing or Damaged Vmm32.vxd File in OSR2.1 Setup – Q167889
ErrMsg: VMM32.VXD: Missing/Unable to Load – Q191874
Error Message: VMM32.VXD Is Required to Run Windows… – Q194679
Err Msg: Invalid VxD Dynamic Link Call from VPOWERD(06)… – Q194999
Computer Stops Responding After You Press CTRL+ALT+DELETE – Q195164
Digital Sound System: Windows Is Unable to Detect DSS80 Speakers – Q220821
Err Msg: Unpacking Vmm32.vxd, Library Invalid or Wrong Version – Q296579

Posted in Windows | No Comments

BIOS Beep Codes

March 7, 2008 – 8:45 AM

When you first “boot up” the BIOS takes control of the computer and performs the P.O.S.T (Power On Self Test). At the end of the POST, the computer will play an audible “beep” through either the PC’s internal speaker or through a set of external speakers attached to the computer. If the POST completed successfully without detecting any problems with then system will play a single short beep to let you know the test is complete and the computer will continue to startup and load the operating system. If the BIOS detects a problem during POST it will normally display a visual error message on the monitor explaining what the problem is. However, if a problem is detected before the BIOS initializes the video card, or a video card is not present or not detected, then the BIOS will play several “beeps” through the speaker to let you know there is a problem. Depending on the type of the BIOS you have the BIOS may play beeps in a specific pattern to indicate what the problem is, or play the same beep a number of times indicating the problem. It is very important that you pay close attention to the number and/or pattern of the beeps your computer plays on startup.

Choose your BIOS and determine the codes:

AMI (American Megatrends International) BIOS.

AMI uses beeps of the same length and pitch. The error is coded as a number of beeps. For example, 4 beeps indicated a timer failure.

Code	Meaning	Possible Cause
1 Beep (No video)	Memory refresh failure	Bad memory
2 Beeps	Memory parity error	Bad memory
3 Beeps	Base 64K mem failure	Bad memory
4 Beeps	Timer not operational	Bad motherboard
5 Beeps	Processor error	Bad processor
6 Beeps	8042 Gate A20 failure	Bad CPU or Motherboard
7 Beeps	Processor exception	Bad processor
8 Beeps	Video memory error	Bad video card or memory
9 Beeps	ROM checksum error	Bad BIOS
10 Beeps	CMOS checksum error	Bad motherboard
11 Beeps	Cache memory bad	Bad CPU or motherboard

Award BIOS.

Award BIOS uses beeps of different durations. A long beep will typically last for 2 seconds while a short beep will last only 1 second. Award BIOS also uses beeps of different frequency to indicate critical errors. If an Award BIOS detects that the CPU is overheating it may play a high pitched repeating beep while the computer is running.

Code	Meaning	Possible Cause
1 Long, 2 Short	Video adapter failure	Bad video adapter
Repeating (Endless loop)	Memory error	Bad memory or bad connection
1 Long, 3 Short	Video adapter failure	Bad video adapter or memory
High freq. beeps (while running)	CPU is overheating	CPU fan failure
Repeating High, Low beeps	CPU failure	Bad processor

Phoenix BIOS.

Phoenix BIOS uses beep code patterns to indicate problems. In the table below the “-” indicates a brief pause between beeps.

Code	Meaning	Possible Cause
1 – 1 – 2	CPU / motherboard failure	Bad CPU / motherboard
1 – 1 – 3	CMOS read/write failure	Bad motherboard
1 – 1 – 4	BIOS ROM failure	Bad BIOS chip
1 – 2 – 1	Timer failure	Bad motherboard
1 – 2 – 2	DMA failure	Bad motherboard
1 – 2 – 3	DMA failure	Bad motherboard
1 – 3 – 1	Memory refresh failure	Bad memory
1 – 3 – 2	64K memory failure	Bad memory
1 – 3 – 3	64K memory failure	Bad memory
1 – 3 – 4	64K memory failure	Bad memory
1 – 4 – 1	Address line failure	Bad memory
1 – 4 – 2	Parity error	Bad memory
1 – 4 – 3	Timer failure	Bad motherboard
1 – 4 – 4	NMI port failure	Bad motherboard
2 – 1 – 1	64K memory failure	Bad memory
2 – 1 – 2	64K memory failure	Bad memory
2 – 1 – 3	64K memory failure	Bad memory
2 – 1 – 4	64K memory failure	Bad memory
2 – 2 – 1	64K memory failure	Bad memory
2 – 2 – 2	64K memory failure	Bad memory
2 – 2 – 3	64K memory failure	Bad memory
2 – 2 – 4	64K memory failure	Bad memory
2 – 3 – 1	64K memory failure	Bad memory
2 – 3 – 2	64K memory failure	Bad memory
2 – 3 – 3	64K memory failure	Bad memory
2 – 3 – 4	64K memory failure	Bad memory
2 – 4 – 1	64K memory failure	Bad memory
2 – 4 – 2	64K memory failure	Bad memory
2 – 4 – 4	64K memory failure	Bad memory
2 – 4 – 4	64K memory failure	Bad memory
3 – 1 – 1	Slave DMA failure	Bad motherboard
3 – 1 – 2	Master DMA failure	Bad motherboard
3 – 1 – 3	Interrupt controller failure	Bad motherboard
3 – 1 – 4	Slave IC failure	Bad motherboard
3 – 2 – 2	Interrupt Controller failure	Bad motherboard
3 – 2 – 3	<RESERVED>
3 – 2 – 4	Keyboard control failure	Bad motherboard
3 – 3 – 1	CMOS batter failure	Bad CMOS battery
3 – 3 – 2	CMOS configuration error	Incorrect setting
3 – 3 – 3	<RESERVED>
3 – 3 – 4	Video memory failure	Bad video card or memory
3 – 4 – 1	Video init failure	Bad video card or memory
4 – 2 – 1	Timer failure	Bad motherboard
4 – 2 – 2	CMOS shutdown failure	Bad motherboard
4 – 2 – 3	Gate A20 failure	Bad motherboard
4 – 2 – 4	Unexpected interrupt	Bad processor
4 – 3 – 1	RAM test failure	Bad memory
4 – 3 – 3	Timer failure	Bad motherboard
4 – 3 – 4	RTC failure	Bad motherboard
4 – 4 – 1	Serial port failure	Bad motherboard
4 – 4 – 2	Parallel port failure	Bad motherboard
4 – 4 – 3	Coprocessor failure	Bad motherboard or CPU.
9 – 2 – 1	Video adapter incompatibility	Try using a different brand of video card

Posted in General BS, Hardware | No Comments

Windows XP Professional How-Tos

Topics on this Page:

Desktop Management

Plan/Deploy

Operate/Administer – User Interface

Operate/Administer – Multimedia

Operate/Administer – Performance

Operate/Administer – Resource Management

Operate/Administer – User Management

Support/Troubleshoot

Internet Browsing and Web Services

Networking

Security

Setup Hardware