|
POST
|
Anyone else getting this error today? my.esri.com 502 Bad Gateway
... View more
01-18-2019
11:15 AM
|
1
|
4
|
3058
|
|
BLOG
|
Original GPS backpack $50,000 each In Depth Tutorials and Information What-when-how: GLOBAL POSITIONING SYSTEM (GPS) -
... View more
01-16-2019
04:59 PM
|
0
|
0
|
526
|
|
BLOG
|
Try using one of these digitizing boards to input everything, The Kurta 12" x 12" digitizing tablet, And the Calcomp 44" x 60" digitazing board digitize kurta calcomp
... View more
01-16-2019
04:51 PM
|
0
|
0
|
479
|
|
BLOG
|
You think you have printing problems? Try using this Ammonia-powered Blueprint Machine for a several hours each day. How to use a Blueprint Machine
... View more
01-16-2019
10:16 AM
|
0
|
0
|
623
|
|
BLOG
|
Lettering with a Leroy Lettering Set The Museum of Forgotten Art Supplies
... View more
01-16-2019
10:05 AM
|
0
|
0
|
1293
|
|
BLOG
|
Remember this? VINES is an acronym for Virtual Integrated NEtwork Service. Like Novell NetWare, VINES's network services were based on the archetypical Xerox XNS stack. James Allchin, who later worked as Group Vice President for Platforms at Microsoft until his retirement on January 30, 2007, was the chief architect of Banyan VINES. VINES technology[edit] VINES ran on a low-level protocol known as VIP—the VINES Internetwork Protocol—that was essentially identical to the lower layers of XNS. Addresses consisted of a 32-bit address and a 16-bit subnet that mapped to the 48-bit Ethernet address to route to machines. This meant that, like other XNS-based systems, VINES could only support a two-level internet. A set of routing algorithms, however, set VINES apart from other XNS systems at this level. The key differentiator, ARP (Address Resolution Protocol), allowed VINES clients to automatically set up their own network addresses. When a client first booted up it broadcast a request on the subnet asking for servers, which would respond with suggested addresses. The client would use the first to respond, although the servers could hand off "better" routing instructions to the client if the network changed. The overall concept very much resembled AppleTalk's AARP system, with the exception that VINES required at least one server, whereas AARP functioned completely "headlessly". Like AARP, VINES required an inherently "chatty" network, sending updates about the status of clients to other servers on the internetwork. Rounding out its lower-level system, VINES used RTP (the Routing Table Protocol), a low-overhead message system for passing around information about changes to the routing, and ARP to determine the address of other nodes on the system. These closely resembled the similar systems used in other XNS-based protocols. VINES also included ICP (the Internet Control Protocol), which it used to pass error-messages and metrics. At the middle layer level, VINES used fairly standard software. The unreliable datagram service and data-stream service operated essentially identically to UDP and TCP on top of IP. However VINES also added a reliable message service as well, a sort of hybrid of the two that offered guaranteed delivery of a single packet. Banyan offered customers TCP/IP as an extra cost option to customers of standard Vines servers. This extra charge for TCP/IP on Vines servers continued long after TCP/IP server availability had become commoditized. At the topmost layer, VINES provided the standard file and print services, as well as the unique StreetTalk, likely the first truly practical globally consistent name-service for an entire internetwork. Using a globally distributed, partially replicated database, StreetTalk could meld multiple widely separated networks into a single network that allowed seamless resource-sharing. It accomplished this through its rigidly hierarchical naming-scheme; entries in the directory always had the form item@group@organization. This applied to user accounts as well as to resources like printers and file servers. #StreetTalk #VIP #ARP #RTP #ICP #TCPIP
... View more
01-16-2019
09:54 AM
|
0
|
1
|
4752
|
|
BLOG
|
Remember this? Quarterdeck Expanded Memory Manager (QEMM) is a memory manager produced by Quarterdeck Office Systems in the late 1980s through late 1990s. It was the most popular third-party memory manager for the MS-DOS and other DOS operating systems. Memory management[edit] Main article: DOS memory management DOS was originally designed for the Intel 8086/8088 processor and therefore could only directly access a maximum of 1 MB of RAM. Due to PC architecture only a maximum of 640 KB (known as conventional memory) is available as the upper 384 KB is reserved. QEMM Configurations[edit] QEMM provides up to 635K free conventional memory (RAM under 640K), far better than pure MS-DOS EMM386, FreeDOS JEMM386, UMBPCI and many other memory manager programs. QEMM maximum RAM is 635K free conventional memory with up to 256MB XMS/256MB EMS shared. MS-DOS 6.22, Windows 3.11/WFW 3.11[edit] QEMM provides the best benefits to MS-DOS 6.22 or older since DOS's. MS-DOS 6.22 provides 619K free conventional memory and up to 64MB XMS/32MB EMS shared RAM. Assuming unaltered MS-DOS 6.22, without 3rd party utilities, i.e. JEMM, UMBPCI, etc. QEMM increases the available free conventional RAM to 635K with shared 256MB XMS/256MB EMS. While using Windows 3.11 or Windows For Workgroups 3.11, QEMM provides additional free conventional memory for DOS Prompt running under Windows. QEMM is well suited for Windows 3.x as has supported for it since QEMM v5.x as early as 1990. As a result, QEMM 8.03 or QEMM 97 integrate very well with Windows 3.11/WFW 3.11. Version history[edit] Originally, the product was called QEMM-386 (require an intel 80386), and was released with a complementary product called QRAM (for use on intel 80286 and 8088). The 386 suffix was dropped starting with QEMM version 7.0 in 1993, when Intel released the Intel Pentium on 3/22/1993. The final release was re-branded as QEMM 97 to follow Microsoft's new branding trend of using year released instead of version numbers, specifically, Windows 95 and Windows 95 OSR2. QEMM-386 v4.2 (1988-11-22)[edit] Supported intel 80386 and DOS 3.30. Bundled with QRAM for 80286 or 8088/8086 computers. QEMM-386 v5.0 (1990-01-11)[edit] Added support for intel 80486, DOS 4.01 and Windows 3.0. Maximum RAM is 16MB XMS/16MB EMS. LOADHI.SYS now loads 2 device drivers at a time. New QEMM parameters include COMPAQ386S (C386S). QEMM-386 v5.11 (1990-08)[edit] QEMM supports moving and reallocating extended memory block, Virtual DMA Services (VDS) specification. QEMM supports systems with large memory cache. qemm loadhi.sys References: QEMM - Wikipedia DOS - Wikipedia
... View more
01-16-2019
08:46 AM
|
0
|
0
|
5550
|
|
POST
|
Hi K B, This Esri business partner has a module for street signs. Government Asset Management Software | Cartegraph
... View more
01-15-2019
01:03 PM
|
0
|
0
|
2378
|
|
POST
|
Hello Abdelhakim, How about create a new empty feature class in the new geodatabase using one of the feature classes as a template. Verify you can edit it to create and delete a few features. Then try load or append again.
... View more
01-14-2019
08:31 AM
|
0
|
0
|
3290
|
|
BLOG
|
Progress in Retinal and Eye Research Retinal-Connectomics-Towards-Complete-Accurate-Networks (attachment)
... View more
01-11-2019
01:20 PM
|
0
|
0
|
421
|
|
BLOG
|
The Human GIS - Individualized Medicine from Prewomb to Tomb
... View more
01-11-2019
01:16 PM
|
0
|
0
|
287
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 07-06-2026 08:49 AM | |
| 1 | 05-02-2023 01:45 PM | |
| 1 | 04-17-2026 02:53 PM | |
| 1 | 06-13-2025 09:16 AM | |
| 1 | 01-18-2019 11:15 AM |
| Online Status |
Offline
|
| Date Last Visited |
Tuesday
|