text:
A method for dynamically caching data objects in a logical cache memory begins by organizing the logical cache memory into a set of maximally equally-sized, contiguous pages that begin at a logical cache base address. Any one of the maximal size logical cache pages may be dynamically subdivided into a set of smaller pages of equal size. The smaller size pages cache data objects having a smaller size than the maximum possible data object size. Each subdivided page stores only those smaller size data objects. The logical address for a page is mapped to at least a maximal size page index identifying the position of the maximal size logical page in the cache and, if the page is a smaller size page, the page location is also mapped to a smaller size page index which identifies a particular one of the smaller size pages located within a maximal size page. Pages are dynamically reconfigured based on a least-recently-used policy. A maximal size page may be reconfigured to provide for storage of multiple smaller sized pages and a set of smaller sized pages may be reconfigured to provide storage for a maximal size page. In one aspect, maximally sized pages may be chained together to provide for storage of data objects which exceed the size of the pages. Chained pages may be contiguous or non-contiguous.
1. A method for dynamically reconfiguring a maximal size logical cache memory page to store a data object having a size different from the size of a data object previously stored by that logical cache memory page, the method comprising the steps of:
(a) at an application server
(i) determining an associated size of a data object;
(ii) transmitting the data object and the associated size of that data object to a client workstation;
(b) at the client workstation
(i) receiving the data object and the associated size, wherein the associated size of the data object is smaller than a maximal size of a logical cache memory page;
(ii) determining whether one of a plurality of logical cache memory pages is already configured to store data objects having the smaller size of the received data object;
(iii) selecting, when no logical cache memory page is already configured to store data objects having the smaller size of the received data object, one of the logical cache memory pages which is the maximal size; and
(iv) reconfiguring the selected maximal logical cache memory page into more than two equally-sized blocks for storing data objects having the smaller size of the received data object.
2. The method of claim 1 wherein step (b)(i) comprises assigning the data object a quantized size by rounding the size of the received data object up to a predetermined quanta.
3. The method of claim 2 wherein step (b)(iv) comprises subdividing the selected logical cache memory page into a plurality of equally-sized smaller pages, each equally-sized smaller page configured to store data objects of the quantized size and identified as storing data objects of the quantized size.
4. The method of claim 3, further comprising the step of mapping a logical address of the data object relative to a logical cache base memory address by:
mapping the logical address of the data object to a maximal size page index corresponding to the page location of the maximal size logical cache memory page relative to the logical cache memory base address; and
mapping the logical address of the data object to a smaller page index that describes which of the plurality of smaller pages is being addressed within the maximal size page designated by the maximal size page index.
5. The method of claim 4 further comprising the step of generating the logical address of the data object by forming a product of the maximal size page index of the maximal size logical cache memory page that contains the data object and a value corresponding to the maximum number of objects of the smaller size that can be contained within the maximal size logical cache memory page, forming a sum of the product and the smaller page index, and multiplying the sum by the quantized size of the data object.
6. The method of claim 4, further comprising the step of providing the mapped logical address for the data object as a single handle.
7. The method of claim 1 wherein step (b)(i) comprises assigning the data object a quantized size selected from a set consisting of 128 bytes, 512 bytes, and 2 kilobytes, wherein the quantized size is assigned by rounding the size of the received data object up to the next predetermined size in the set.
8. The method of claim 1 wherein the data object received in step (b)(i) is a graphical user interface data object to be cached.
9. The method of claim 1 wherein step (b)(ii) comprises determining more than one of the plurality of logical cache memory pages that are configured to store data objects having the smaller size of the received data object.
10. The method of claim 1 wherein step (b)(iii) comprises selecting, when no logical cache memory page is already configured to store data objects having the smaller size of the received data object, one of the plurality of logical cache memory pages on a least recently used basis.
11. A method for dynamically reconfiguring a maximal size logical cache memory page to store a data object having a size different from the size of a data object previously stored by that logical cache memory page, the method comprising the steps of:
(a) at an application server
(i) determining an associated size of a data object;
(ii) transmitting the data object and the associated size of that data object to a client workstation;
(b) at the client workstation
(i) receiving the data object and the associated size, wherein the associated size of the data object is greater than a maximal size of a logical cache memory page;
(ii) subdividing the data object into first and second data chunks;
(iii) assigning a first chunk index to the first data chunk and a second chunk index to the second data chunk, each index representing the maximal size logical cache memory page in which the respective data chunk is stored; and
(iv) storing the second chunk index at a location in a control store that corresponds to the first chunk index for use in identifying the location of the second data chunk.
12. The method of claim 11 wherein step (b)(iv) comprises storing the second chunk index at the location in the control store that corresponds to the first chunk index for use in identifying the location of the first and second data chunks.
13. The method of claim 11 further comprising the steps of:
(b)(v) accessing the control store using a first page index corresponding to the first chunk index;
(b)(vi) recovering an index stored in the control store starting at a location corresponding to the first chunk index; and
(b)(vii) reading a maximal size logical cache memory page corresponding to the first chunk index.
14. A method for efficiently caching data objects in a logical cache memory including a plurality of maximal size pages beginning at a logical base memory address, the logical cache memory using prescribed portions of a plurality of heterogeneous physical memory units for storage of data, the method comprising:
(a) at an application server
(i) determining an associated size of a data object;
(ii) transmitting the data object and the associated size of that data object to a client workstation;
(b) at the client workstation
(i) labeling each of the plurality of heterogeneous physical memory units with a unique rank index, the rank index indicative of the relative memory speed of the physical memory unit;
(ii) allocating a portion of each physical memory unit for use by the logical cache memory;
(iii) forming a continuous, addressable logical address space for the logical cache memory that encompasses the allocated portions of the physical memory units by ordering the allocated portions of the physical memory units based on the rank indices of the logical cache memory beginning at a logical cache memory base address, each maximal size page configured to store data objects of a maximal size and identified as storing data objects of a maximal size;
(iv) receiving the data object and the associated size, wherein the associated size of the data object is smaller than the maximal size;
(v) determining whether one of the plurality of logical cache memory pages is already configured to store data objects having the smaller size of the received data object;
(vi) selecting, when no logical cache memory page is already configured to store data objects having the smaller size of the received data object, one of the logical cache memory pages which is the maximal size; and
(vii) reconfiguring the selected maximal logical cache memory page into more than two equally-sized blocks for storing data objects having the smaller size of the received data object.
15. The method of claim 14 wherein step (b)(iv) comprises assigning the data object a quantized size by rounding the size of the received data object up to a predetermined quanta.
16. The method of claim 15 wherein step (b)(vii) comprises subdividing the selected cache page into a plurality of equally-sized smaller pages, each equally-sized smaller page configured to store data objects of the quantized size and identified as storing data objects of the quantized size.
17. The method of claim 16, further comprising the step of mapping a logical address of the data object relative to the logical cache base memory address by:
mapping the logical address of the data object to a maximal size page index corresponding to the page location of the maximal size logical cache memory page relative to the logical cache memory base address; and
mapping the logical address of the data object to a smaller page index that describes which of the plurality of smaller pages is being addressed within the maximal size page designated by the maximal size page index.
18. The method of claim 17 further comprising the step of generating the logical address for the data object by forming a product of the maximal size page index of the maximal size page that contains the data object and a value corresponding to the maximum number of objects of the smaller size that can be contained within the maximal size page, forming a sum of the product and the smaller page index, and multiplying the sum by the quantized size of the data object.
19. The method of claim 17, further comprising the step of providing the mapped logical address for the data object as a single handle.
20. The method of claim 14 wherein step (b)(iv) comprises assigning the data object a quantized size selected from a set consisting of 128 bytes, 512 bytes and 2 kilobytes; wherein the quantized size is assigned by rounding the size of the received data object up to the next predetermined size in the set.
21. The method of claim 14 wherein the data object received in step (b)(iv) is a graphical user interface data object to be cached.
22. The method of claim 14 wherein step (b)(v) comprises determining more than one of the plurality of logical cache memory pages that are configured to store data objects having the smaller size of the received data object.
23. The method of claim 14 wherein step (b)(vi) comprises selecting, when no logical cache memory page is already configured to store data objects having the smaller size of the received data object, one of the logical cache memory pages for reconfiguring on a least recently used basis.
This application is a continuation of U.S. patent application Ser. No. 08/541,128, filed on Oct. 11, 1995.
The invention relates to efficiently caching graphical user interface (GUI) objects in the memory of a user workstation. The GUI objects are sent from an application server to a user workstation within a distributed process system over a common low bandwidth transport mechanism.
Distributed process systems, in which the technique of distributing an application execution is used, are similar to the traditional multi-user systems such as Unix. From a graphics standpoint, the distributed process systems are similar to X-Windows. The technique of distributing an application execution is called Distributed Application Presentation (DAP).
In a DAP system, an application server provides application execution services to network users rather than running the application at the user's workstation. When the application runs, the application server intercepts the application user's interface (e.g., the display screen, keyboard, and mouse) data and transmits/receives this data to/from a small client (user) program running at the user's workstation. More advanced DAP systems operate in a highly integrated network environment in which an application server technology is coupled with local area network (LAN) or wide area network (WAN) transport systems as shown in FIG. 1. The host computer 300 is coupled to LAN/WAN transport system 304. This coupling, that allows the LAN/WAN network administrator to more widely distribute the services of application servers 302 to user workstations 305, requires that the host computer be able to support the simultaneous execution of multiuser applications including support of workstation interfaces such as: keyboard, mouse, and display screen. The most prevalent use of application servers is in dial-in remote access DAP systems.
When running an application on an application server, the user is not actually executing the application code on the user's local workstation. Therefore, in order to make the application server's remoteness transparent, the user workstation storage disks and printers must be accessible by the application server.
The workstation includes the following capabilities:
(1) a protocol for transmission of display screen, keyboard, mouse, file, and printer data;
(2) a layered distribution architecture for transmission of the protocol packets;
(3) a client program that can run on the user workstation for protocol interpretation; and
(4) a configuration application for configuring the application distribution protocol stack for accommodating a variety of transport media and client types.
When the workstation is operating as a virtual computer, it is running a client program which transmits and receives Windows-type object level protocol packets. The workstation also handles protocol packets for controlling printing and storage disk operation. If the workstation is a fixed function system, such as an ASCII text terminal, the protocol of the terminal is used.
FIG. 2 shows the major workstation protocol layers of a commercial application server system called "WinFrame ™" manufactured by Citrix Systems, Inc. of Coral Springs, Fla. The WinFrame™ workstation is called "WinStation". The present invention has been implemented in a system of this type and hence the WinFrame™ system will be used as a basis for describing the invention by way of explanation only and not by way of limitation of the scope of the invention.
Referring to FIG. 2, the three major sets of protocol layers are: the WinStation Driver (WD) set 10 acting as the workstation data stream manager that includes ICA, the protocol used for communication of screen, and mouse and keyboard updates, between the application server and the workstation; the protocol driver (PD) set 20 of optional communications protocol layers such as data compression, encryption, reliability (error control), and modem control; and transport drivers 21 for connecting the workstation to the connection (transport) medium.
ICA, a line protocol used to communicate Windows application presentation data with the application server over a low Ad. bandwidth connection, includes protocol definition for the following capabilities:
(1) full-screen text presentation,
(2) Windows application screen presentation,
(3) keyboard and mouse input,
(4) session control,
(5) framing of data for asynchronous connections,
(6) error detection and recovery,
(7) compression and encryption hooks,
(8) file system redirection,
(9) print redirection, and
(10) multiple generic virtual channels.
ICA uses packet communication techniques for communications between the application server and the workstation. The packet, shown in FIG. 3, can be prefixed by optional preambles, negotiated when a connection is established, for managing the transmission of the packet. The nature of the transmission medium (e.g., LAN or Async) and user defined options (e.g., compression, encryption) determine the total packet definition, but the overall packet format is as shown in FIG. 3. The labeled segments are defined as follows:
Frame Head--optional preamble protocol header for framing stream oriented transport data;
Reliable--optional preamble protocol header in packet for transmission error detection and correction;
Encrypt--optional preamble protocol header for managing encrypted data;
Compress--optional preamble protocol header for managing compressed data;
COMMAND--ICA command byte marking the beginning of the base ICA protocol packet;
COMMAND DATA--optional data bytes associated with the specified COMMAND segment that can include virtual channel protocol packets; and
Frame Trail--optional protocol trailer (postamble) for framing ASYNC transport data.
Only the COMMAND byte is always present in the packet. The preambles and postamble are dependent upon the transport used and the initialization negotiations.
The ICA COMMANDS include control commands and virtual channel commands.
The ICA control COMMAND packets manage the connection of the workstation to the application server and the server relationship to workstation interface. The COMMAND packets include information on:
(1) connection initialization;
(2) workstation (client) interface and display screen control;
(3) workstation keyboard and mouse input to the application server; and
(4) workstation keyboard light emitting diode (LED) display control.
The ICA virtual channel COMMAND packets provide multiplexed management of multiple virtual channels. A virtual channel is used to add functional enhancements to the client independent of the ICA protocol. The virtual channel is a session-oriented transmission connection that can be used by the application layer code. The ICA virtual channel COMMAND protocols include: Thinwire, Printer Mapping, and Drive Mapping.
Thinwire--is used to transmit presentation commands to the client workstation from Windows applications running on the application server. It is designed to use low bandwidth connections between the server and the workstation by using such techniques as:
(1) command and object specific compression;
(2) outboard complex clipping and complex curve drawing;
(3) efficient caching of Windows objects (bitmaps, brushes, glyphs, and pointers); and
(4) run-length encoding.
Printer Mapping--is a virtual channel protocol for the transmission of printer data to the client workstation.
Drive Mapping--is a virtual channel protocol for the transmission of file system functions between the application server and the client workstation.
FIG. 4 shows the Citrix Systems WinStation 100 and WinFrame™ Application Server 200 Communications Stack architecture as a set of component definitions. WinStation 100 is a system component capable of displaying application data and transmitting application input data to the server. The WinStation assumes many forms such as a simple text terminal, a personal computer (PC) emulating a terminal, or a PC running a program (or terminal) that implements the ICA protocol. The functionality of the WinStations and the method of communicating with the server may differ but the architecture shown in FIG. 4 accommodates these differences.
The architecture of FIG. 4 is defined in terms of the protocol layers and their specific responsibilities. At the top of both Application server 200 and WinStation 100 are the respective data sources 210 and 110. In the case of unit 110, a display screen, keyboard, and mouse are shown and function as both a data destination and data source. As previously mentioned, the WinStation 100 may take on a variety of configurations depending on the user needs. The protocol layers are defined as follows.
WinStation Driver (WD) 10 is responsible for interpreting the data stream generated by the WinStation or Application Server. The WD is tailored to each WinStation: it is different for each type of workstation (e.g. a dumb terminal or an ICA terminal).
Protocol Driver (PD) 20 is a communications layer added to the protocol stack for preparing the data to be transmitted to the corresponding WinStation or Application Server. Because all PDs support the same interfaces, each PD can be inserted or removed from the stack in accordance with the needs of each connection. The order in which the PDs are stacked is controlled by the configuration process.
Transport Driver (TD) is a PD for interfacing the stack to the system provided transport service 300 and is tailored to the type of transport service being used by each WinStation.
Protocol Advertiser (PA) 50 is used by each Application Server for broadcasting that a particular Application Server is on-line and functioning. In this way, a WinStation, using the same transport service, may be made aware its availability.
Protocol Listener (PL) 40 provides an Application Server with the capability to listen for connection requests from WinStations.
Name Resolver (NR) 30 is unique to the type of network to which the WinStation is connected, provides network name-to-address translation.
Name Enumerator (NE) 31 is unique to the type of network to which the WinStation is connected and provides enumeration of all on-line Application Servers on the network.
Virtual Driver (VD) 60 is for running the virtual channel protocols as defined in the ICA. The VD supports a generic set of interfaces that are accessible through system
Application Protocol Interfaces (APIs) and communicates with the WD through a special interface.
The Application Server 200 of FIG. 4 includes a Win 32 Subsystem 210 for the management of an associated client WinStation for which application services are to be provided. As shown in FIG. 5, subsystem 210 includes the Client Server Runtime Subsystem (CSRSS.EXE) Process 230 and Protocol Service Process 240. Process (CSRSS.EXE) 230 controls WinStation Driver Stack 220, a dynamic linkable library (DLL) of protocols, through WinCon Server 231 by creating the control datastream needed to control the WinStation being accessed. WinCon Server 231 contains all the console (text window) code and APIs. WD Stack 220 includes WD 10, PDs 20, and TD 21, each of which is a DLL driver.
ThinWire Driver 60 is controlled by Graphical Device Interface (GDI) Server 233 and User Server (USER) 232. GDI Server 233 is the graphics portion of the Win32 subsystem that contains all of the graphics code and APIs. USER 232 is the non-graphics portion of the Win32 subsystem that contains the remaining APIs not contained in WinCon Server 231 or GDI 233.
Protocol Service Process 240, controls PL 40 and PA 50 for effecting a connection between the Application Server and the WinStation requiring service. A PL 40 and PA 50 pair is provided for each type of transport that is supported by the system. The PA 50 broadcasts the Application Server's availability on a network while the PL40 listens for service requests from WinStations on a network.
The WD interface of WD Stack 220 provides WinCon Server 231 with display function information, display mode control, and session connect/ disconnect information for handling full screen text transmission and WinStation initialization. Keyboard and mouse input is delivered to WinCon Server 231 through the WD interfaces. Each WD maintains a FIFO (first-in, first-out) queue for mouse and keyboard input events. A raw input thread (RIT) in process CSRSS takes its input events from this queue.
The WD Stack 220 is defined by a configuration utility named WINCFG. When a WD is defined or when the Win32 Subsystem is started, the DLLs are loaded. FIG. 6 shows the Win32 Subsystem stack components. The PD 20 and TD 21 components are as previously described. The WinStation Drivers (WDs) include: ASCII terminal WD for terminals like the DEC VT420 from Digital Equipment Corp. and the Citrix ICA 3.0 WD.
ICA WinStation, a DOS (disc operating system) program for connecting to and communicating with the Application Server using the ICA protocol, is modular and can be dynamically configured and customized with different user interfaces and optional virtual channel capabilities. FIG. 7 is a graphical representation of ICA WinStation 110 that shows ICA WinStation 110 as an executable (.EXE) DOS program that includes User Interface (UI) 111 and Libraries (.LIB) 112 operating on an assortment of DLLs that are run-time loaded and linked. The Libraries can be linked with the User Interface and DLLs to provide system independent interfaces and ease in porting to non-DOS platforms.
UI 111 is the master controller of the ICC WinStation and has responsibility for:
(1) establishing and maintaining configuration data;
(2) loading required protocol components;
(3) running a polling loop; and
(4) presenting a local user interface.
In order to make a connection to a specific- application server, UI 111 maintains configuration information for the connection that includes any name-to-address translation data and a list of protocol stack components (PDs and TD) and protocol parameters required. When an Application Server is selected by the user, the UI loads the appropriate stack components and passes the user selected parameters to the Application Server based upon the configuration data. Configuration Libraries (CFGs), based on Initialization (.INI) files, are used to simplify-the loading and linking process. The connection process is initiated by a UI call to the ICA WD 10 at the top of the stack with a connection initiation command. The connection process is asynchronous. UI 111 starts its polling loop by keying off the connection status that is returned. Once the connection status is established, UI gives up focus (i.e. ownership of the keyboard, mouse, and display screen) to the WD. The UI remains the master and continues to run the polling loop. WD gives up focus when the connection is broken.
While a connection exists, UI 111 can query statistics and error conditions and, can also terminate the connection. If a connection is broken, UI 111 is responsible for cleaning-up is by unloading all of the stack components.
There are four .INI files associated with UI 111:
(1) MODULE.INI that lists the protocol-stack components;
(2) APPSRV.INI that describes the application server configuration;
(3) MODEM.INI that describes the modem management strings; and
(4) WFCLIENT.INI that lists the user configurations.
Winstation Libraries 112, a set of run-time libraries that simplify customization of components, includes:
(1) clib, a C-language run-time library subset;
(2) cfg, libraries for configuration and standard operations such as loading and linking;
(3) ini, functions for access of INI style parameters;
(4) video, keyboard, mouse, timer, and parallel port libraries for access to these hardware components;
(5) xms, extended memory allocation libraries; and
(6) logging, functions for standard logging and tracing facilities.
These libraries are directly linked to by the UI EXE and are accessible to the DLLs indirectly through the DLL interface process.
ICA WD 10, when it has focus, controls the presentation of a specific WinStation protocol on the local screen display and also manages the communication of the keyboard and mouse inputs to the Application Server. Focus is given to ICA WD 10 by UI 111, as previously described.
ICA WD 10 gets its protocol packets from the topmost PD on PD stack 20. When ICA WD 10 links with this PD, it registers an input processing entry point. This entry point is called when a data packet is available. When ICA WD 10 needs to write data, it calls the PD using a PD write function.
ICA WD 10 also responds to the polling function of UI 111 and passes it on to lower stack layers. State data is reported by this method so that, for example, if a lower layer detects that a connection is broken, this status information is passed up to UI 111 through the return codes of the polling functions.
ICA WD 10 also provides a general purpose virtual channel capability represented by the set of virtual channel drivers (VDs) 60 described below.
ICA WD 10 provides a set of Application Program Interfaces (APIS) that includes:
(a) Load () for loading and linking a driver into the protocol stack;
(b) WdUnload() for unlinking and unloading a driver from the protocol stack;
(c) WdOpen for opening and initializing a driver;
(d) WdClose for closing a driver;
(e) WdInfo for querying driver information;
(f) WdPoll for getting status and giving control to drivers in the protocol stack;
(g) WdQueryInformation for querying modem status, mouse information, last error, and statistics; and
(h) WdSetInformation for connecting, disconnecting, setting or killing a focus.
All protocol drivers (PDS) 20 have the same interfaces and are dynamically loaded and linked in the same manner by UI 111. Also, a PD may be added or removed from the configuration without changing the underlying code.
Because of some interdependencies, PDs 20 must be loaded in a specific order, e.g. the Compression PD requires the framed packet of the framing PD.
The WinStation includes the following optional PDs:
(a) a Compression PD for compressing and decompressing of raw data;
(b) a Reliable PD for error handling for unreliable transport such as IPX and Async;
(c) a Framing PD for framing of stream type data from Async and TCP transport services into packets;
(d) a Modem PD for managing the establishment of a modem connection; and
(e) an Encryption PD for encrypting data.
The WDs and PDs each provide a set of Application Program Interfaces (APIs) that includes:
(a) Load () for loading and linking a driver into the protocol stack;
(b) WdUnload()/PDUnload() for unlinking and unloading a driver from the protocol stack;
(c) WdOpen/PdOpen for opening and initializing a driver;
(d) WdClose/PdClose for closing a driver;
(e) WdInfo/PdInfo for querying driver information;
(f) WdPoll/PdPoll for getting status and giving control to drivers in the protocol stack;
(g) PdWrite for writing data;
(h) WdQueryInformation/PdQueryInformation for querying modem status, mouse information, last error, or statistics;
(i) WdSetInformation/PdSetInformation for connecting, disconnecting, setting and killing focus.
The Transport Drivers (TDs) are similar to the PDs, i.e. the top interfaces are the same and TD loading, linking, and polling are done in the same way. The TDs differ from the PDs because the bottom interface of each is for a specific transport service. For example, the DOS IPX TD is programmed for the Novell IPX DOS INT for reading and writing packets over the underlying IPX network.
The WinStation client includes the following TDs 20:
(a) an IPX (Internet Packet Exchange) TD is a NetWare LAM communication protocol for moving data between server and/or workstation programs running on different network nodes;
(b) an SPX (Sequenced Packet Exchange) TD is an enhanced set of commands implemented on top of IPX for creating a true transport layer interface;
(c) a TCP/IP (Transmission Control Protocol) TD is an Internet protocol suite providing reliable, full duplex, stream service.
(d) a NetBIOS (Network Basic Input/Output System) TD is an application programming interface for data exchange between a server and/or workstation programs running on different network nodes; and
(e) an Async TD is the standard interface to an RS-232 type asynchronous transport service.
The TD APIs are similar to those listed for the PDs/WDs above.
Name Resolver (NR) 30 is a DLL module for providing network name-to-address translation of a selected application server to UI Ill of FIG. 7. NR 30 specific APIs include: Load(), NrUnload(), NrOpen(), NrClose(), NrInfo(), NrPoll(), NrName ToAddress(), and NrErrorLookup().
Name Enumerator (NE) 31 of FIG. 7 is a DLL module for enumerating all available application servers on the network. NE 31 specific APIs include: Load(), NeUnload(), NeOpen(), NeClose(), NeInfo(), NePoll(), and NeEnumerate().
Virtual Channel Driver (VD) set 60 are directly connected to ICA WD to allow application level communication to be multiplexed with the display protocol. The set of VDs support the following functions:
(a) client printer mapping for allowing a printer device on the Application Server to be redirected to a printer on the client computer;
(b) client drive mapping for redirecting drive letters on the Application Server to drive letters that exist on the client computer; and
(c) Thinwire presentation protocol for operating the WD protocol as a virtual channel.
VD set 60 includes the following APIs: Loado, VdUnload, VdOpen, VdClose(), VdInfo(), VdPoll(), VdQueryInformation, and VdSetlnformation().
Scripting 32 (FIG. 7) is an optional DLL that is an extension of UI 111 for prerecording keystrokes and responses to display screen output for automating some user operations.
Because the application server and the user workstation are generally physically separated and are only linked by a transport mechanism for communications that is of lower bandwidth than that required to directly support the workstation display if it were part of the application server's host system, it is highly desirable to have an efficient method to send graphical data and control messages from the application server to the workstation. This objective has been traditionally achieved by using bandwidth compression techniques for more efficient use of the common transport system.
The use of bandwidth compression techniques for the transmission does not, per se, remove the need to recreate the original data (and bandwidth) required for driving the workstation display. The original bandwidth requirement obtains after the reduced bandwidth encoded message is expanded to the original form required to drive the workstation display. For example, the graphical data could be encoded by using a code book in which each complex graphical object is represented by a simpler numerical code. Upon receipt of the coded graphical data, each numerical code would be decoded at the workstation by entering a copy of the code book using an address corresponding to the numerical code and retrieving the corresponding complex graphical instruction. This implies the need for a large fast cache memory with sufficient bandwidth to support the workstation graphics.
The ability to effectively and efficiently cache graphical user interface (GUI) objects such as bitmaps, glyphs, pointer images, and brushes is essential for enabling the user to perceive a responsive and well performing GUI application at the workstation even though the GUI application code is executing remotely.
Because the workstation cache capacity is potentially limited, it is important that GUI objects of different types and sizes be able to efficiently share cache memory in the workstation. Prior art caching methods for GUI objects preassigned separate fixed size memory areas for each object type and for each size. Consequently, the cache resources cannot be dynamically assigned or reassigned between different object types and between different size groups within the same object type. This leads to the following limitations in the prior art:
(1) the workstation is unable to initialize and establish a connection with the application server if the fixed memory size areas required by the workstation are not available for caching;
(2) if the exact fixed size memory area required for a specific object type and size is not available for caching, even if a smaller size memory is available, the workstation is unable to use the smaller memory area and will not cache any objects of that type and size;
(3) if a user has heavy usage of one object type and is not using any other object type, the unused cache area is not available for caching the object type that is being used.
Additional prior art limitations include;
(a) the specific cache area assigned for storing each specific workstation GUI object type must be contiguous; and
(b) the number of object types and sizes is limited so that the application server's servicing is further restricted.
The present invention solves the prior art problems by providing a method for efficiently caching GUI objects in a workstation cache memory by maximizing the use of available cache memory to store the GUI objects and thereby reducing the bandwidth requirements for the common transport mechanism used for communications between the application server and the client workstation in a distributed process system.
The GUI caching method and system includes the following features:
(a) each workstation has a set of selectable cache memory pages of differing sizes for storing GUI objects of differing page sizes, each page being directly accessible for reading or writing;
(b) cache memory pages of different sizes dynamically share the same logical cache address space for optimal use of available cache memory based on object usage patterns;
(c) each cache memory page is capable of being chained with any other page for writing and reading a logical sequence of cache memory pages; and
(d) chained cache memory pages can be read by using a single memory address to the first cache memory page of the chained cached memory pages.
The present invention may be more fully understood from the detailed description given below and from the accompanying drawings of the preferred embodiments of the invention, which, however, should not be taken to limit the invention to the specific embodiment but are only for explanation and understanding.
FIG. 1 shows a distributed application presentation system.
FIG. 2 shows the major workstation protocol layers of a distributed process application server system.
FIG. 3 shows a communication packet format used in the distributed process system.
FIG. 4 shows the communication stack architecture of a commercial distributed process application server system.
FIG. 5 shows the processes of the application server.
FIG. 6 shows the application server protocol stack architecture components.
FIG. 7 is an architectural representation of an ICA type workstation.
FIG. 8 is a block diagram of a workstation showing the physical memories.
FIG. 9 shows a workstation logical GUI object tiny cache and large cache.
FIG. 10 is a table showing different chunk types and cache memory allocations.
FIG. 11 is a memory allocation map for a GUI object large cache memory.
FIG. 12 shows the mapping process between a GUI large cache logical address space and a physical address space.
FIG. 13 is a flow diagram for assigning GUI object handles.
FIG. 14 is a flow diagram for mapping logical cache addresses into physical memory unit addresses.
FIG. 15 shows how a GUI object logical address in logical cache is used to access a chained object in physical memories.
FIG. 16 is a flow diagram for writing GUI oversized chunk type objects into the client workstation GUI object cache using chaining.
FIG. 17 is a flow diagram for reading oversized (chained) chunk type objects from the GUI object cache.
The available bandwidth of the common transport mechanism in a distributed process system is generally small compared to the bandwidth required to feed a workstation display screen in support of an application that is executing at a remote application server but is displaying results on the workstation display screen. The effective bandwidth at the display has to be sufficient to support the illusion that the application is executing locally without the constraints imposed by the restrictive bandwidth of the transport mechanism.
Because the caching space in the workstation is potentially limited, it is necessary that all available cache capacity be used efficiently. This requirement .implies the following considerations:
(a) memory space available for caching may not be contiguous;
(b) cache memory space must appear as a single logical cache area even if the memory resources are a heterogenous collection of non-contiguous memory spaces with different operating characteristics;
(c) available cache memory must accommodate a large variety of GUI objects of differing types and sizes;
(d) each GUI object stored in cache must be read-accessible by a single handle regardless of size; and
(e) available cache space must be dynamically adaptable to accommodate the GUI object usage of the applications currently using the workstation display.
The cache protocol recognizes two different logical cache areas labeled the "tiny cache" and the "large cache". The size of the tiny cache can be 0 to 32K bytes in 32 byte increments. However, a size of less than 8K bytes is not recommended for the tiny cache. The size of the large cache can be 0to 8M bytes in 2K byte increments.
Each logical cache area has a contiguous range of logical (versus physical) addresses used to store one or more "chunk types". A chunk type identifies the size of the object for data being stored in the cache area.
FIG. 8 shows a workstation 400 in which three different types of physical memory are used: local memory 404, fast and directly accessible to the CPU; extended memory 405, moderate speed and accessible to the CPU by the memory bus; and bulk memory array 406, slow mechanical disk drive arrays. CPU bus 408 interconnects CPU 401, display 402, keyboard 403, local memory 404, and memory/system bus control 407. Fast local memory 404 and memory/system bus control 407 are also connected to memory/system bus 409 for providing CPU 401 access to extended memory 405 and bulk memory array 406.
The GUI object cache memory that has one or more contiguous logical segments can use all or some of these physical memories. Also, there may be multiple logical segments using the same physical memory type. Physical memories are prioritized by bandwidth so that a performance optimizing memory allocation for GUI object cache is made by choosing the higher bandwidth memories first and allocating the slower memories only when faster memory capacity is exceeded. FIG. 9 shows workstation 400 in which the a logical large GUI object cache 410 has been created that includes three logically contiguous segments (411, 412, and 413) that are physically portions of memories 404, 405, and 406 of FIG. 8, respectively. The logical addresses begin with 00 . . . 0 at the lower end of GUI object cache 410 and increment in 2KB page steps through memories 411-413. Tiny cache 420 is also a logical memory structure preferably created as part of local memory 404.
A given protocol packet addressing cache 410 or 420 contains a "client object cache handle" and a chunk type. The chunk type determines the size of the object and, together with the client object handle, determines the offset into the appropriate logical cache area. The sizes of the two cache areas are determined by the client and the sizes are reported as parameters by the client workstation to the application server during the connection procedure.
The tiny cache is used exclusively for storing objects of chunk type 32B that are <32 bytes in size. The client object cache handle for a chunk type 32B is 10 bits long so that 1024 different 32 byte size areas can be accommodated in the tiny cache. If the tiny cache is smaller than 32K bytes then the application server will not generate handles for access to addresses outside the range of the specified tiny cache size. If the tiny cache resides solely within the directly addressable memory of 1K bytes, 5 bits of the object cache handle can be used to specify the offset into the area of tiny cache 420 of FIG. 9.
The large cache 410 (FIG. 9) is used for objects with many different chunk types. All of the varied chunk type objects share the same contiguous set of logical addresses. The application server is responsible for maintaining cache consistency as different size objects share the large cache.
The chunk type of a given object is used together with the client object cache handle to determine the logical address (offset) into the large cache. The client object cache handle contains the object number (starting with 0) for the corresponding object size. The object offset into the large cache is computed by multiplying the size of the object by the client object cache handle. The offset is added to the start of the large cache independent of-the chunk type (size). Because the client object cache handle is specified by a field of 12 bits (212 =4096), the larger chunk types can extend deeper into the large cache, i.e. beyond the offsets of the smaller size chunk types.
FIG. 10 is a table showing the chunk types that share the large cache. The columns are organized as follows: the first lists the chunk type (monochrome pointer, 128B, 512B, 2KB); the second lists the corresponding sizes in bytes; the third lists the corresponding maximum number of objects and the number of bits required parenthetically; and the fourth lists the total cache space in bytes that can be occupied.
FIG. 11 is a memory map showing the regions of large cache address space that can be used for each chunk type listed in FIG. 10. The top to bottom order of lines, that shows the allowable region for storage, corresponds to the order of chunk types listed in FIG. 10: monochrome pointer, 128B, 512B, and 2KB. The regions in which the lines overlap demonstrate the concept of different chunk types sharing common regions of large cache.
In order to simplify the implementation, the first 2K of the large cache of FIG. 11 is only used to store the monochrome pointer chunk type of objects. The rest of the large cache is shared between chunk types 128B, 512B, and 2KB. The way in which this sharing is done is as follows: a single 2K byte area (or maximal page) in the large cache that starts on a 2K byte logical address boundary can be assigned to hold objects of the same chunk type at a given time. Thus, a 2K byte area can be assigned to store objects of the same chunk type (or page size), i.e. a single 2KB chunk type object, 4 different 512B chunk type objects, or 16 different 128B chunk type objects.
The usage of each 2K address range in the large cache can change as each 2K area is re-used. At a given time, it can store a single 2KB chunk type object, and at another time it can store up to 4 512B or 16 128B chunk type objects. For simplicity in cache management, a given 2K address range is not used to store a mixture of 128B and 512B chunk type objects. Also, because the lower 2K bytes of large cache are reserved for monochrome pointer type objects (FIG. 11), the client object cache handle has a minimum values of 1, 4 and 16 for chunk type objects 2KB, 512B, and 128B respectively.
In order to relate a logical address of the large GUI cache to a physical address in a memory unit (e.g. 404, 405, or 406 of FIG. 8), a memory address mapping process, such as that shown in FIG. 12, is used by CPU 401 (FIG. 8). The application server specifies a GUI object by sending a corresponding client object cache handle and chunk type to the workstation in a virtual channel protocol packet. This logical address corresponds to the desired GUI object in GUI cache memory 410, as shown in FIG. 9. Referring to FIGS. 8, 9, and 12, mapping process (MAP) 600 determines which physical memory unit (404-406) corresponds to the given logical address. It should be recalled that the logical cache memory 410 is organized from several heterogenous physical memories arranged in hierarchical order of speed. Thus, local memory 404 provides storage for cache addresses 00 . . . 0 up to (but not including) AA . . . A, shown as logical cache memory section 411. MAP 600 identifies any address in this range as belonging to physical memory unit 404 and corresponds to a stored entry in segment 411' between address DD . . . D and address EE . . . E. The data location in memory unit 404 is determined by using the product of the client object cache handle and the GUI object size as an offset from address DD . . . D. Similarly, any logical address ≧AA . . . A and <BB . . . B is mapped onto space 412' of memory unit 405. The offset from address AA . . . A, is used to find the offset from address FF . . . F in section 412' of memory unit 405. Similarly, higher order addresses for logical memory addresses from BB . . . B to CC . . . C would be mapped to section 413' of physical memory unit 406. It should be noted that this procedure for mapping logical to physical memory addresses may be applied to GUI caches using one or more physical memory units and, consequently, multiple logical address ranges may map to different portions of physical memory units of the same type.
To help in understanding the dynamic operation of the large cache memory, assume that all 2K byte areas have been allocated for the storage of various chunk types. For purposes of control, the application server maintains a LRU (least recently used) list of all the 2K areas in the large cache. If the application server needs to put a GUI object in the large cache, it determines the GUI object chunk type and then proceeds as follows:
(a) if the GUI object is a 2KB chunk type, then the least recently used 2K area in the large cache is used for caching the GUI object;
(b) if the GUI object is a 512B chunk type, and no free 512B areas exist, the least recently used 2K area that is addressable by a 512B chunk type object (see FIG. 11) is used and is subdivided into 4 512B areas (areas 0-3). Area 0is used to cache the current 512B chunk type and the cache control storage marks area 0 as allocated. This leaves 3 512B unallocated areas. The client object handle is the 2K area number multiplied by 4 plus the 512B area number. Additional 512B chunk type areas are allocated as required, from the remaining 512B areas defined in the current 2K area. Once all 512B areas in a given 2KB area are allocated, a new 2KB area is selected using the LRU rule described; and (c) if a 128B chunk type object is to be cached, the procedure is the same except that the LRU rule selected 2KB area is subdivided into 16 128B areas. The client object cache handle is obtained by multiplying the 2K area number by 16 and then adding the 128B area number to the product. FIG. 11 shows that fewer 2K areas are addressable for caching the 128B chunk types than for the 512B chunk types. Different chunk type objects do not intermix in a given 2KB area.
In this manner, client object cache handles are assigned independent of the order of arrival of the various chunk type objects. The cache is dynamically adapted to the caching requirements of a given application by assigning cache resources to the application as needed.
FIG. 13 is a flow diagram for process 500, named ASSIGN-- --OBJECT-- HANDLE, that assigns GUI object handles for large cache 410 (FIG. 12). The method checks if the GUI object to be cached is of chunk type 2KB in step 501. If it is, step 502 uses the LRU rule to select a 2K area in the cache region not allocated to monochrome pointers (FIG. 11). Having selected a 2K area (slot), step 503 computes the client object cache handle by setting it equal to the 2K slot number selected by the LRU rule and the procedure ends. If step 501 determines that the GUI object is not chunk type 2KB, step 504 determines if the GUI object is of chunk type 512B and, if so, proceeds to step 505 to determine if a size 512B area (slot) is available. If not, step 506 uses the LRU rule to select the least recently used 2K slot from the contiguous set of 2K slot available for caching 512B chunk type objects. Step 507, allocates the selected 2K slot for use for caching 512B chunk type objects and assigns the lowest order 512B slot (0) to the current GUI object that is to be cached. Otherwise, if a 512B slot is available, step 508 stores the GUI object in the next 512B slot available in the 2KB slot currently allocated for 512B chunk type object storage. At step 509, the client object handle is calculated by multiplying the 2K slot number by 4 and then adding the 512B slot number to that product. If step 504 determines that the GUI object is of chunk type 128B (by not being chunk type 512B), step 510 checks if a 128B slot is available, and, if not, proceeds to step 511 where the LRU rule is used to select a suitable 2K slot from the set of 2K slots available for 128B chunk type object caching. Step 512 allocates the selected 2K slot for storage of 128B chunk type objects and assigns the current 128B GUI object to the lowest slot (0). Otherwise, step 513 uses an available 128B slot to store the current GUI object. Step 514 computes the client object cache handle by forming the product of the 2K slot number and the value 16 to which the 128B slot number is added.
FIG. 14 is a flow diagram for MAP 600, a method for mapping large cache 410 (FIG. 12) logical addresses to physical addresses for accessing physical memory spaces that correspond to the logical cache memory spaces. The method assumes that a given object is identified by its handle, h(n,k), and size (type), S(k); logical memory addresses begin at zero; logical memory is made up of M contiguous sections, each section having a lower boundary logical address, L(m), and an upper boundary logical address U(m), for m=0, 1, . . . , M-1; and each contiguous memory section, m, corresponds to a section of physical memory of rank m and is located at the physical base address of B(m).
Step 601 of FIG. 14 computes the starting logical address, a(n,k) from the product h(n,k)�S(k) which is compared with the upper logical boundary address U(m) in step 602. If a(n,k) is greater than U(m), index m is incremented in step 603 and step 602 is repeated. Otherwise, step 604 determines that the object starts in the mth physical memory unit. Step 605 and 606 are used to determine the index me of the highest rank section in which storing of the object ends, Step 605 compares the quantity {a(n,k)+S(k)} with the upper logical boundary address, U(m). If U(m) is smaller, step 606 increments index m and step 605 is repeated. Otherwise, step 607 sets the highest rank containing the object at m=me.
At this point, MAP 600 of FIG. 14 has provided the necessary information to map the logical object address to the physical address: rank index values mb and me define the limits of the physical ranks m that are involved in the cache access (mb ≦m≦me). The remaining steps 608-612 are concerned with generating the required offset addresses for accessing the corresponding portions of physical memory. Step 608 sets index m=mb. Step 609 accesses the physical memory section of rank mb memory unit beginning at address B(mb)+a(n,k)-L(mb). Step 610 checks if all required ranks have been accessed and, if not, m is incremented in step 611 for accessing the rank m physical memory beginning at base address B(m) in step 612. Test step 610 is then repeated.
Thus, the large cache has a variety of page sizes, one for each chunk size, all dynamically sharing the same logical cache unlike conventional prior-art cache structures that have only one page size.
The cache protocol also supports the caching of objects of size greater than 2KB by using the innovative concept of "chaining". Chaining is a method for creating a virtual cache chunk page (or superpage) by using a cache with smaller chunk pages. The superpage capacity is an integer number of times larger than the smaller page. For example, a cache with 2KB size chunk pages (maximal size pages) can be used to produce a cache for storing 10KB chunk type superpage by chaining five of the maximal (2KB size chunk) pages so that a single cache access is sufficient to access the lOKB virtual superpage.
Chaining is accomplished by identifying the first 2KB portion of the larger chunk type by using the client object cache handle and a chunk type of 2KB, as if it were a 2KB object. The remaining 2KB segments of the larger object are identified by using a "chain handle" for each additional 2KB segments of the larger object. The chain handle has the same format (and interpretation) as a client object cache handle used for the 2KB chunk types. The workstation cache manager is responsible for remembering all the chain handles associated with a given client object cache handle and chaining the segments in the order received. In this manner, the application server can efficiently initiate the retrieval of a larger workstation GUI object while minimizing bandwidth utilization of the common transport mechanism.
FIG. 15 shows how a GUI object logical address in logical cache 410 is used to access a chained object in physical memories 404, 405, and 406 (FIG. 8). In this example, a chained object in logical cache 410 is shown to span a chained object space from within logical cache segment 411, through segment 412, and into segment 413. The starting address of the chained object in segment 411 is sent to process CHAIN-- READ 800 where a control storage is examined to determine if the object stored at the starting address is a chained object. If it is, the control storage yields a list of sequential chain handles that map to a list of logical cache addresses identifying the logical cache memory segments that contain the chained object. This information is passed on to process MAP 600 (previously described) that converts the logical addresses into a set of sequential addresses for accessing the relevant physical memory segments 411', 412', and 413'.
FIG. 16 is a flow diagram of CHAIN-- WRITE 700, the chaining procedure used by the system for writing a chained object into the client GUI object cache. It is assumed that a GUI object is to be sent for caching that is greater than 2KB, the maximal chunk type object that the cache can accommodate without chaining. In step 701 the application server assigns a client object cache handle to the GUI object that is to be sent for caching at the client workstation by using method 500 (ASSIGN-- OBJECT-- HANDLE) of FIG. 13. Method 500 is applied to each 2KB chunk of the GUI object by having step 702 check if there is another 2KB chunk to be chained. If so, the procedure returns to step 701. Otherwise, in step 703, the application server sends the chained oversized chunk type size and object to the client. The object is sent as a series of chained 2KB psuedo-chunk type objects, each with an associated chain handle. The client workstation recognizes that this is a chained object because of its superpage size and, in step 704 stores the psuedo objects according to the object handles associated with each psuedo-chunk type object. In step 705, the client workstation enters the chained oversized chunk type object size and series of 2KB psuedochunk type object handles in the cache control store so that when the oversized object is called from cache, the control store can recognize the oversized object's size and determine the location of each 2KB psuedo-chunk type object.
CHAIN-- READ procedure 500 in FIG. 17 is a flow diagram that describes the method used to read chained oversized objects from the GUI object cache at the client workstation that have been cached in accordance with CHAIN-- WRITE procedure 700 of FIG. 16. At step 801, the application server sends .a GUI object cache memory read for an oversized GUI object by simply sending the psuedo-chunk type object cache handle of the first 2KB psuedo-chunk type object (the client object cache handle). At step 802, the client enters the control store using the first 2KB psuedo-chunk object handle and gets the next 2KB psuedo chunk handle. Step 803 reads the current physical cache address computed from the current handle to obtain the object data. If the last psuedo-chunk type object has been read, the procedure ends. Otherwise the procedure returns to step 802.
Because of the method and apparatus described above, it is possible to efficiently and effectively cache as many different GUI object types and sizes in a given allocated size of workstation cache memory and thereby-improve the utilization of the available common transport bandwidth and the utilization of available memory resources. Both of these benefits lead to improved workstation performance for the user whose application is being served remotely.
It should also be noted that the techniques described above should prove useful for caching tasks other than graphical object caching whenever a variety of page sizes are to be accommodated within a cache memory or, whenever a variety of heterogenous physical memories are to be used for synthesizing a single logical cache. For example, a conventional prior-art fixed page cache when augmented with chaining can provide a cache with flexible page sizes.
As will be understood by those skilled in the art, many changes in the apparatus and methods described above may be made by the skilled practitioner without departing from the spirit and scope of the invention, which should be limited only as set forth in the claims that follow.
Patent Citations
Non-Patent Citations
Referenced by
Legal Events
Original Image


text:
Event Details
|Makah Landowner Outreach Session
Dates: 05/14/2014
Time: 9:30 AM to 5:30 AM
Location: Bellingham, WA
|Summary: Outreach meetings providing information about the Department of the Interior's Land Buy-Back Program for Tribal Nations and assistance in filling out purchase offer packages for Makah allotments will be held in the Olympic Peninsula and Puget Sound areas.
|Fees: Free
Staff from the Makah Realty Office and Office of the Special Trustee for American Indians will be presenting an overview of the Land Buy-Back Program, assisting in filling out packages, and answering questions.
Please bring photo-identification if you need your deed notarized at the meeting.
Program purchase offers are sent to landholders through the mail. Therefore, it is critical that landholders ensure their mailing address is current by calling the Trust Beneficiary Call Center at 1-888-678-6836.
Click here for more information.
|Contact: Dale Denney, Makah Realty
|Email: n/a
|Phone: 360-645-3106

subset: commoncrawl


text:
Find the perfect hotel in Dundee using our hotel guide provided below. Search for the cheapest discounted hotel and motel rates in or near Dundee, FL for your personal leisure or group travel. Explore the most favored Dundee, Florida hotel and motel rooms. Browse the Dundee area hotels to find the perfect lodging! Please use the provided map of the Dundee hotels. Coordinating a group? Get Dundee Group Hotel Rates
Dundee Hotels, Motels & Accommodations
Next 20 Dundee Hotels > [1 - 20 of 50]
Next: See My Dundee Hotels with Pricing >


text:
With a strong running game, anchored by Ivan Wiggins, and an opportunistic defense that scored two touchdowns, the Military Magnet Eagles whipped Stall, 38-21, on Thursday night.
Wiggins, a 5-3, 140-pound sparkplug, rushed for more than 100 yards as the Eagles rolled up more than 250 yards on the ground to improve to 3-2 on the season. The Eagles also returned two interceptions for touchdowns and forced six turnovers.
"This is a good building block win for us, and I thought our guys played very hard all night," said Military Magnet head coach Gene Ross. "I am really proud of our kids. They played their tails off tonight and made a lot of good things happen."
Military Magnet totally dominated the first half of play as Stall struggled offensively. The Warriors had three turnovers on their first eight offensive snaps and Magnet took advantage.
Military Magnet covered 79 yards on its first possession, with DeAngelo Rivers capping the eight-play drive with a 13-yard run four minutes into the game.
Stall (1-3) answered on the ensuing kickoff as Dominique Richardson returned the kick 68 yards for a touchdown. Joe Vasquez's extra point put Stall on top, 7-6.
Early in the second quarter, Michael Richardson scored on a one-yard run to give Magnet a 12-7 lead.
Two minutes later, Kadeem Woods intercepted a Benjie Wright pass and returned it 45 yards for a touchdown, pushing the lead to 18-7.
Stall fumbled on the first play of its next possession, and five plays later, Rivers connected with Byron Fazio on a four-yard scoring toss for a 24-7 lead.
Stall finally put together a solid offensive drive just before the half. The Warriors went on a 71-yard drive with Wright hitting Jordan Carswell with a 21-yard touchdown pass with 1:13 left in the half, cutting the halftime margin to 24-14.
The Warriors had two more turnovers in the second half, one leading to a five-yard TD run by Wiggins and the other a 22-yard interception return for touchdown by Marcus Dickinson with 9:28 left in the game.
Stall's final TD came on Wright's 34-yard strike to Cars-well that cut the lead to 38-21.
Military Magnet 6 18 0 14—38
Stall 7 7 0 7—21
MM – DeAngelo Rivers 13 run (run failed)
S – Dominique Richardson 68 kick return (Joe Vasquez kick)
MM – Michael Richardson 1 run (pass failed)
MM – Kadeem Woods 45 interception return (run failed)
S – Jordan Carswell 22 pass from Benjie Wright (Vasquez kick)
MM – Ivan Wiggins 5 run (run failed)
MM – Marcus Dickinson 22 INT return (Wiggins run)
S – Carswell 34 pass from Wright (Vasquez kick)
Notice about comments:
The Post and Courier is pleased to offer readers the enhanced ability to comment on stories. Some of the comments may be reprinted elsewhere in the site or in the newspaper. We ask that you refrain from profanity, hate speech, personal comments and remarks that are off point.
We do not edit user submitted statements and we cannot promise that readers will not occasionally find offensive or inaccurate comments posted in the comments area. If you find a comment that is objectionable, please click the X that appears in the upper right corner when you hover over a comment. This will send the comment to Facebook for review. Please be reminded, however, that in accordance with our Terms of Use and federal law, we are under no obligation to remove any third party comments posted on our website. Read our full terms and conditions.


text:
Questions? Call Us 866-733-0698
The Lesro Classic Series of office furniture has an incredible offering of various tables and seating solutions that are sure to look great in any office environment. Whether you are looking for a single seat or connecting guest seats, rounded back chairs, square back or backless seating, rolling guest chairs, or nearly any other configuration imaginable, the Lesro Classic Series has the perfect furniture piece to meet your exact needs. Items in this series are available in a variety of fabric choices and wood finish options, so it is easy for you to customize your purchase to match your existing office furniture and décor.
67 Item(s)
Page 1 of 3 |
1 2 3
Next >>


text:
The Emirates Stadium club have gone eight years without a piece of silverware and that has added pressure on boss Arsene Wenger.
But a 10-game unbeaten run at the end of last season helped secure another finish inside the Premier League's top four and Walcott hopes to continue that momentum.
"It is quite frustrating at times, because we should have done that at the start of the season," he told Sky Sports. "Who knows where we would have been.
"We need to remember those moments that we had and make sure we do it from the start, because we could be challenging for anything. We could beat anyone.
"We want that sort of fear factor, especially at the Emirates."


text:
You have no items in your shopping cart.
Designed with a modern straight fit and a regular rise. The leg opening measures 16". We've included a dual finish buckle button, Volcom embroidery on the top right back pockets, and a new back pocket shape with a 2-needle topstitch hem. But the high quality features don't stop there. We've also included off stitching on the back left pocket, new zippers with a dual finish, a Stone embroidery with indigo dyed thread, dual finish hardware, and signature black and white threading. Featured colorway is Rinse.
For a stylish look that's both casual and comfy, the Lived In Stripe Long Sleeve Tee is the perfect pick. Features a scoop neckline with contrast binding plus a fashionable handkerchief inspired hemline and front pocket. Length is 24 inches from shoulder to hem.
Things get easier with the Creak In Tee. Abstract lines from abstract minds equals pure originality.
Volcom and Electric team up on the next generation of oversized goggles. The EG3 V. CO-LAB Goggle features the Electric Press SEAL* system, ensuring an airtight lens to frame seal. Engineered with industry leading technology, the EG3 is suited for the experienced, tech savvy rider who is looking for world-class optics, optimal peripheral vision and superior fit.
Okay Mountain •
1619 E Cesar Chavez St, Austin, TX 78702
March 14, 2014
Click To Download This Instagram Image!
Volcom - NYC
446 Broadway, New York City, NY 10013


text: Baked has a factory full of motherly Italian women to thank for its streak-free finish. But we're not responsible for any Italian-style stares you attract. We're all for the joys of baking – just never in the sun – which is why we created Baked Bronzer. Explore the tantalizing range of shades and finishes if your objective is alluring sun-kissed skin that looks totally natural! This super fine powder is baked on a terra cotta disc for 24 hours and then hand-finished by a factory full of motherly Italian women.


text:
Good stuff in the section this week. Read these, won't you?
Rising Brazilian electro-pop star Luisa Maita.
My review of Tuesday's show by The Shins.
The John Butler Trio at Clear Summer Nights.
The Devil Whale and The Parson Red Heads at McMenamins.
And an update on the Sisters Starry Nights organization, how they're adjusting to the economy, and what they've got planned for this year (and tonight).
Elsewhere in the music section: Taarka, Mary Kadderly, Early Melodic Animals, Bex, Uncle Lucius, Brent Alan, Brad Tisdel.


text:
Root Catalog
Shop by Brand
30 Items
Sandia Raven 10-0197 XP-3 Whisper 6 Quart Microfiltration Vacuum Bag BULK CASE LOT, 50 Pack.$127.50This is BULK CASE LOT purchase of 50 total 6 quart microfiltration vacuum bags for the Sandia 6 quart backpacks. Save BIG off retail price when purchasing bulk. These bags Fit the following Sandia Plastics XP-3 Whisper 6 WERK.20 models; 74-2012, 74-2016, Learn More
Sandia Raven XP-3 Whisper 6 Quart HEPA Filtration Backpack Vacuum Bags, 6 Pk.$25.99These are 6 High quality HEPA filtration vacuum cleaner bags that fit all 6 quart Sandia backpacks. Rather then the standard paper bags which can exhaust microscopic particles, the disposable cloth style of HEPA filtration bag keeps these airborne allerge Learn More
Sandia 6 Series 10-0197 10 Pack Generic Vacuum bags$19.95Sandia 6 Series 10-0197 10 Pack Generic Vacuum bags Better filtration means cleaner air, less dusting, longer secondary filter life, at considerable savings. Learn More
Sanyo Cannister Type SC-P7 [3 Bags per pack]$9.99Sanyo Cannister Type SC-P7 [3 Bags per pack] Learn More
Sanyo SC-PU1 Vacuum Bags [3 pack]$12.99Sanyo Upright Model SC-PU1 [3 Bags per pack] Learn More
Sanyo HEPA Filter Assembly Bagless Canisters$44.99Genuine Sanyo Filter for the Yellow Colored SC270, and SC27Y, and also fits the Sanyo bagless canister model SC240, and SC24Y models. Filter is sold as a complete assembly with bracket and filter included. Learn More
Sanyo Bagless Upright 12 inch Roller Brush Part 6490002487$30.99This is a high quality replacement roller brush made by Cleavland Wood Products, the leader and highest quality generic roller brush maker on the market. MADE IN THE USA. CWP actually is the manufacturer of many OEM roller brushes, so their quality and Learn More
Sanyo Cords$24.95Sanyo Cords 1 pc. Learn More
Sanyo Lights$7.95Sanyo Lights 1 pc. Learn More
Sanyo Switches$11.95Sanyo Switches 1 pc. Learn More
SANYO MODEL SC-240 HOSE PART NUMBER # 6161039057$41.14SANYO MODEL SC-240 HOSE PART NUMBER # 6161039057 Learn More
Sanyo Genuine Sanyo Vacuum Crevice Tool$10.97Genuine Sanyo vacuum cleaner crevice tool fits uprights in the model range B1210B1230 and U127U129 Learn More
Sanyo Canister Vacuum Cleaner Model SC30, 585, 535 Crevice Tool$5.32Works with: Sanyo SC30, Sanyo 585, Sanyo 535 Learn More
Sanyo Vacuum Cleaner Brush Roll - Genuine$45.97Sanyo vacuum cleaner brush roll fits upright vacuum cleaner model A114. Genuine Sanyo vacuum part. Learn More
Sanyo Model A115, A116 Upright Vacuum Cleaner Brushroll$64.40Works with: Sanyo A115, Sanyo A116, Sanyo A127C Learn More
Sanyo For Kenmore Vacuum Cleaner Pre Filter$12.32Works with: Sanyo , Sanyo 535, Sanyo 545, Sanyo 585 Learn More
Sanyo Type P11, SC-P11 Transformax Vacuum Cleaner Bags Transformax Vacuum Cleaner Bags P-11$21.96Works With: Sanyo P11 Sanyo SC-P11 Sanyo Transformax Description:10 Genuine Sanyo Bags In Pack Learn More
Sanyo Model SC-X2100P, SC-FH2 Canister Vacuum Cleaner Filter$22.77Works with: Sanyo SC-X2100P, Sanyo SC-FH2, ##Sanyo 93-2356-07 Learn More
Sanyo Canister Type SC-P7 Bags +$9.83This Sanyo Canister Type SC-P7 Bags comes in a Pack of 3. Learn More
Sanyo Bagless Upright 12 inch Replacement Roller Brush (Beater Bar) to Fit Sanyo Part 6490002487.$30.88This is a high quality replacement roller brush made by Cleavland Wood Products, the leader and highest quality generic roller brush maker on the market. MADE IN THE USA CWP actually is the manufacturer of many OEM roller brushes, so their quality and performance are identical, but the price is a fraction of the genuine Sanyo brush. This 12" Roller Brush will fit all Sanyo bagless uprights that use a 12" roller brush. Learn More
Sanyo SC-PU110 Upright Bags -10 pack$12.32Quantity Per Package: 10 Sanyo vacuum bags OEM Part Number: SC-PU110 Learn More
Sanyo Vcauum Cleaner Exhaust Filter$12.73Sanyo vacuum cleaner exhaust micron filter fits models A111 and A113. Genuine Sanyo vacuum part. Learn More
Sanyo Upright Vacuum Cleaner Belts$5.77Works with: Sanyo SC, Sanyo U, Sanyo SC-BL1 Learn More
xSanyo Vacuum Cleaner Filter Sanyo SC-FU1 Vacuum Cleaner Filter$15.49Works With: Sanyo SC-U11MA Sanyo SC-U10MA Sanyo SC-U8MA Sanyo SC-U8WA. Also Fits All Sanyo SC-A Series and Sanyo SC-U Series Description:Sanyo Upright Vacuum Cleaner Filter Model SC-FU1. Fits Models: SC-U11MA, SC-U10MA, SC-U8MA, SC-U8WA. Also Fits All SC-A Series and SC-U Series 1 Genuine Sanyo Filter In Pack SA-18000 Learn More
Sanyo Vacuum Crevice Tool - Genuine$10.97Genuine Sanyo vacuum cleaner crevice tool fits uprights in the model range A110A115, U8MAU11MA and U101U126 Learn More
Sanyo Vacuum Cleaner Genuine Brush Roll$54.97Sanyo vacuum cleaner brush roll fits upright vacuum cleaner models A115, A116 and A127C. Genuine Sanyo vacuum part. Learn More
Sanyo Vacuum Cleaner Filter (6490000674)$9.73Sanyo vacuum cleaner secondary filter, (goes under the paper bag) fits all uprights with 14 inch brush rolls. Genuine Sanyo part 649 000 0674. Learn More
Results 1 - 27 of 30
- 1
- 2


text:
Teddy Barham was born April 1, 1943 in Hugo to Joseph Cullen and Carlene (Blackburn) Barham. He passed from this life on November 4, 2011 in Midwest City, at the age of 68. Teddy graduated from Antlers High School. He had spent the past fifteen years living in Jones, Oklahoma. Teddy was of the Methodist faith, and he enjoyed talking about history, visiting with others, watching television, and spending time with family and friends. Teddy was preceded in death by his parents: Joe & Carlene Barham.
Dovie Elizabeth Dees was born August 18, 1929 in Rattan to Jonathan Thomas and Rolen (Connally) Fleming. She passed from this life on November 1, 2011 in Tuttle, at the age of 82. Dovie was raised in Rattan & attended Rattan Schools into her senior year where she was part of the Ramblers basketball team. In 1947, she met a handsome young man, James Wallace Dees. They were married on December 18, 1947. They lived in California until 1960 when they moved to Oklahoma City where Dovie was a Medical Records Technician at Presbyterian Hospital until her retirement.
Mary L. Lange was born March 26, 1925 in Star City, AR., to William Howard and Delia (Cook) McWhorter. She passed from this life on November 7, 2011, in Hugo, at the age of 86. Mary attended Cosmetology School in Houston, TX. She practiced cosmetology for over 50 years, owning the Classy Cutters Salon in Antlers for over 20 years. She was a member of the Order of the Eastern Star - Chapter 415 in Humble, TX. Mary was a member of Antlers First Baptist Church. She was a people person and enjoyed spending time with family & friends. Mary was preceded in death by her husband: A.W.
Charles Wilburn Parker, of Antlers, was born on October 14, 1926, in Pitcher to Jack John and Edith Marie (Young) Parker. He passed from this life on Tuesday, November 1, 2011, in Oklahoma City, at the age of 85. He lived in Stroud as a child and moved to California as a teen.  He married Ruby Simmons in 1946. Charles retired from Tinker AFB where he was a sheet metal worker.   Following his retirement, he moved to Antlers. Charles loved to hunt and fish. Charles was preceeded in death by: one brother, John Parker and one sister, Saundra Thompson.
There were recently 20 participents at the 1st Annual Moyers Baptist Church Turkey Shoot at the Hugo Lake Shoothing Range. The winners were for small caliber, Randall Miller, for sporting clas, Johnny A. Cole and for large caliber, Joe Standridge.
The Moyers Tigers took on Eagletown last Tuesday night at home. First up would be the Lady Tigers. Kalli Winters would score the first points on a great pass from Shelby Geary. The Lady Eagles were quick to retaliate and quickly jumped out on the Ladies 9-4. At half the Ladies found themselves down 31-8. The 3rd qtr was kinder to the Lady Tigers and their rebounding improved with Shelby Geary hitting the boards hard for the team.Â
On Tuesday, November 15, 2011 at 9:00 a.m. the Antlers Fire Department and the Kiamichi Economic Development District of Oklahoma (KEDDO) a nd the Oklahoma Forestry came together at the Antlers City Hall and developed a Community Wildlife Protection Plan.
Here are this weeks sports venues for Pushmataha County for the week of November 14th - 18th! Make sure you head out and support our young athletes!
• Basketball • Rattan Public School
November 14th: Rattan High School vs. Haworth at 6:30 p.m.
November 15th: Rattan Jr. High vs. ET at 4 p.m.
November 15th: Rattan High School vs. ET at 6: 30 p.m.
November 16th: Rattan Jr. High & Elementary vs. Lane at 11:00 a.m.
• Basketball • Moyers Public School
November 14th: Moyers Jr. High @ Farris starting at 4:00 p.m.
When it comes to Thanksgiving dinner, the turkey is the main attraction of the meal for many families.
Before the golden brown and juicy bird gets placed on the table there are some steps that need to be followed in order to ensure a safe and tasty meal, according to Barbara Brown, Oklahoma State University Cooperative Extension food safety specialist.
We all had trouble not getting swept up in the buzz and media frenzy that surrounded the nuptials of Prince William and Kate Middleton on April 29, 2011, and many Americans woke up in the middle of the night to be apart of this once in a lifetime event.
The children from the Choctaw Nation HeadStart may not have been up watching the extravagant wedding but they did decide not to let the event go unnoticed. They sent the couple many warm wishes and the best of luck in the form of letters and artwork.


text:
Wednesday, August 27, 2014
The Send Off Party for TOUR TO ENABLE will be held on Wednesday Aug. 27 at Liberty Taproom in Mount Pleasant. Great drink specials, a chance to meet the riders before their journey and donate to their cause. The TOUR TO ENABLE is three Charleston area men who are departing Charleston on Aug. 28 for a 3 week, 5,500 mile motorcycle ride to raise $15,000 for the purchase of an All-Terrain wheelchair for The Independence Fund (Indy Fund) – an organization that provides tools and therapies to injured Veterans. Tour to Enable will leave Charleston at 1 p.m. the following day, August 28.
Lucas Cobb, Kevin Duckworth and Ben German work together building websites, one client was the Independence Fund, Inc. Upon learning about the great work the Independence Fund does in helping restore injured Veterans' mobility and quality of life; they just knew they had to help. Raising funds for tan All-Terrain chair to enable a veteran with severe injuries to have the accessibility to a normal life and activities like going to the beach, hunting, and fishing. Whatever they were going to do to raise funds had to be impactful and pay tribute to freedom, independence and mobility. So why not get on motorcycles and ride to Las Vegas and back?
The Challenge is to ride 5,500 miles roundtrip - Charleston to Las Vegas in 3 weeks and raise $15,000. Besides the distance being a challenge, only Kevin is a seasoned motorcycle rider. Ben and Lucas have only been riding since March! Sponsors include Low Country Harley Davidson and Cycle Gear of North Charleston.
"We are thrilled by the innovative way the American people continue to serve our wounded heroes. Every community fundraiser shows our severely injured veterans that they are not forgotten, and that our nation not only owes them a great debt, but that there are people out here ensuring we give back to those that have given the most", said Independence Fund Founder/President, Steve "Luker" Danyluk. The Indy Fund is the producer of the Lt. Dan Band weekend which begins as the Tour to Enable Riders return to Charleston on Sept. 19.
The route is posted on the Tour to Enable website (www.tourtoenable.com) so supporters can follow the map and also keep up with their Twitter posts throughout the journey (@tourtoenable).
They are hoping for local media to chronicle their journey through phone interviews or Skype.
Based in Miami, Florida; The Independence Fund has a 100% volunteer staff and a Board of Directors comprised entirely of combat Veterans. www.independencefund.org
Moultrie News is pleased to offer readers the enhanced ability to comment on stories. We expect our readers to engage in lively, yet civil discourse. We do not edit user submitted statements and we cannot promise that readers will not occasionally find offensive or inaccurate comments posted in the comments area. Responsibility for the statements posted lies with the person submitting the comment, not Moultrie News.
If you find a comment that is objectionable, please click "report abuse" and we will review it for possible removal. Please be reminded, however, that in accordance with our Terms of Use and federal law, we are under no obligation to remove any third party comments posted on our website. Read our full terms and conditions.
© 2015 Moultrie News an Evening Post Industries company. All Rights Reserved.
Registration on or use of this site constitutes acceptance of our Terms of Service, Privacy Policy and Parental Consent Form.


text:
What USB Loader and what version are you using? cIOS don't matter for GC games, only MIOS. If you installed DIOS MIOS correctly then your MIOS is fine.Originally Posted by danielmpr
I think that is part of the intention to add Classic Con support. I know it was discovered that the new Wiis without GC ports still have the MIOS and BC files installed on them so the theory was if there was a way to get the Wii to either recognize the Classic Con in GC mode or get GC games loaded in Wii mode that it would actually work. I don't know for sure if it ever went beyond being a theory. I don't have a newer Wii to try it with but it seems possible seeing as to the new Wiis still have the MIOS and BC files which are needed to run GC games so as long as they can be USB loaded, save to SD via NMM and have a alternate controller it seems it should work. Again, I have no way to confirm or disprove it either way but for all the reading I did about it I couldn't find anything saying it won't work.Originally Posted by candylove
Edit: Yup, according to what I just read on GBAtemp once Classic Con is added new Wii's will be able to play GC games via Devolution. If DIOS MIOS could add that too that'd be awesome.
Sent from my iPhone using WiiHacks
Last edited by SNES_Master; 08-11-2012 at 03:12 PM.
Hello, I also need help trying to play a gamesube iso on my wii.
I followed the softmod any wii guide and also installed DM 2.2 using WAD manager 1.7 through IOS 249, which I am led to believe contains d2x due to the softmod.
My SD card is PNY 8gb SDHC and my USB is PNY 16GB. The usb in in what I believe is slot 0, closer to bottom (rubber "legs") of wii.
I found that the usb should be compatible with usb loader form another site's list and I have backed up wii play onto it and gotten it to play normally with a GC disk in the wii.
Since I don't know if the GC ISO I converted with discex was done correctly I am trying to "install" my gamecube retail discs to the usb and get them to play. I have tried this with both wiiflow r615 and usbloader gx 1198 and couldn't get the games to install successfully with either. wiiflow stayed stuck at 0% though the bar moved a bit at first, and usb loader got to 19% and then froze. I waited for 10 minutes after that but it did not proceed beyond that. The games I tried with were "Monopoly party" and "Fire emblem Path of Radiance", both shown to work normally on my gamecube and wii before the softmods.
any help would be greatly appreciated
SpoilersysCheck v2.1.0b17 by Double_A and R2-D2199
...runs on IOS58 (rev 6176).
Region: NTSC-U
System Menu 4.0U (v417)
Priiloader installed
Drive date: 2007.02.13
Homebrew Channel 1.0.0 running on IOS58
Hollywood v0x11
Console ID: 59237898
Boot2 v3
Found 78 titles.
Found 52 IOS on this console. 3 of them are stub.
IOS4 (rev 65280): Stub
IOS9 (rev 54321): Trucha Bug
IOS10 (rev 768): Stub
IOS11 (rev 54321): Trucha Bug
IOS12 (rev 526): No Patches
IOS13 (rev 1032): No Patches
IOS14 (rev 1032): No Patches
IOS15 (rev 1032): No Patches
IOS16 (rev 54321): Trucha Bug
IOS17 (rev 1032): No Patches
IOS20 (rev 54321): Trucha Bug
IOS21 (rev 1039): No Patches
IOS22 (rev 1294): No Patches
IOS28 (rev 1807): No Patches
IOS30 (rev 54321): Trucha Bug
IOS31 (rev 3608): No Patches
IOS33 (rev 3608): No Patches
IOS34 (rev 3608): No Patches
IOS35 (rev 3608): No Patches
IOS36 (rev 54321): Trucha Bug
IOS37 (rev 5663): No Patches
IOS38 (rev 4124): No Patches
IOS41 (rev 3607): No Patches
IOS43 (rev 3607): No Patches
IOS45 (rev 3607): No Patches
IOS46 (rev 3607): No Patches
IOS48 (rev 4124): No Patches
IOS50 (rev 54321): Trucha Bug
IOS51 (rev 4864): Stub
IOS53 (rev 5663): No Patches
IOS55 (rev 5663): No Patches
IOS56 (rev 5662): No Patches
IOS57 (rev 5919): No Patches
IOS58 (rev 6176): USB 2.0
IOS60 (rev 54321): Trucha Bug
IOS61 (rev 5662): No Patches
IOS70 (rev 54321): Trucha Bug
IOS80 (rev 54321): Trucha Bug
IOS90 (rev 54321): Trucha Bug
IOS202[60] (rev 65535
IOS222[38] (rev 4
IOS223[38+37] (rev 4
IOS224[57] (rev 65535
IOS236 (rev 54321): Trucha Bug
IOS245[37] (rev 21008
IOS246[38] (rev 21008
IOS247[53] (rev 21008
IOS248[55] (rev 21008
IOS249[56] (rev 21008
IOS250[57] (rev 21008
IOS251[58] (rev 21008
IOS254 (rev 65281): BootMii
BC v5
MIOS v10
Report generated on 2012/08/11.
P.S. I tried to provide all the pertinent info I could think of but if I missed something just ask
Well, I downloaded the latest CFGUSBLOADER MOD, and also USBLOADER GX, also, can I install the DIOSMIOS wad with ANY wad manager? does that matter? I'm pulling my hair out here!!! don't think it could be my HDD as it is correctly formatted to 32kb cluster FAT32, and is on the HDD compability list!
in USB Loader GX make sure you check GC in the Loader mode settings on top, no disk in drive, DIOS MIOS 2.2 in the settings
USB Loader GX, go into settings>custom paths, and change the path from SD to USB1:/games/;
WiiFlow you have to select the gamecube button at the bottom of the screen to see the games.
Here: Wiiflow_Mod_svn_r607.zip
or USB Loader GX.
http://code.google.com/p/usbloader-g...?id=1769#c2815, CFG Loader, DIOS MIOS Booter,
I am using wiiflow r607 and USB Loader GX 1200 and they work perfect.
I also use CFG Loader r37 and DIOS MIOS Booter r30
I did not like wiiflow r615
Last edited by candylove; 08-12-2012 at 08:00 AM.
Install DIOS MIOS with any Wad manager ( WiiMod, Multi-Mod Manager etc etc) use IOS 236 for the install. Make sure your HDD, in addition to being Fat32 with 32kb clusters, is primary and active.Originally Posted by danielmpr
Sent from my iPhone using WiiHacks
My wiiflow started giving me and error that i cant figure out how to fix!
when i load it right away a yellow triangle pops up with an exclamation point in the middle i did some reasearch but i just cant get it to work :/
help anyone?
WiiFlow or Wiiflow_Mod_svn_r607.zip
maybe your wiiflow files are corrupt , you should always keep a backup of your SD files.
Last edited by candylove; 08-13-2012 at 07:11 AM.
I want to thank you all for your help. I was having issues getting DML 2.2 working. Turns out it was my setup. I finally got Wiiflow r607 that Candylove mentioned and followed what SNES mentioned about installing DIOS MIOS using the proper IOS.
Now I just need to figure out if it is possible to use WAD Manager from the hard drive.
and WAD-Manager 1.7 to install wads from SD
you do not need a SD card to install wads with WAD Manager 1.8, just put WAD Manager 1.8 in your apps folder on your hard drive and your wads on your hard drive and install
I install DIOS MIOS 2.2 wad with WAD Manager 1.8 from USB and it work perfect.
Last edited by candylove; 08-13-2012 at 03:42 PM.
I spoke too soon seems as though all my wii games will load from the external under the WBFS folder using WiiFlow. My GameCube games are visible when i click on the icon in the bottom, but when I go to play the game it asks me about copying the game over to the SD. Which means I messed something up, or missed something.
I will have to grab the 1.8 version, and toss it onto my drive. Thanks for that tip


text:
Energizer AGM Automotive Battery - Group Size H7 LN4
- Free Pickup
About this item
Today's vehicles have more accessories than ever before: heated seats, power lift gates, alarms, stereo and DVD systems, navigation, and all of the electronics like cell phone, tablets, and laptops that we can no longer live without. All of these accessories takes a toll on the battery, shortening the life of ordinary flooded batteries.
Energizer Absorbent Glass Mat (AGM) batteries with their thick, high density paste and tightly compressed cells are engineered to meet the extreme demands of today's vehicles.
In high heat environments, the dual sealed, valve regulated AGM design creates a recombinant environment in which water loss is not a problem. Combined with their thick patented stamped grid they offer up to 2X the life of flooded batteries.
Energizer AGM batteries are 100% Spill proof, perfect for batteries located in the trunk and passenger compartment.
The lead acid battery is one of the world's most recycled consumer products. Nearly every part of your Energizer automotive battery can be recycled. Please return your used lead acid batteries to your local Sam's Club for free recycling.
Energizer AGM batteries are maintenance free.
Assembled Country