home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 14 Text / 14-Text.zip / xb2wp.zip / xb2wp.asc
Text File  |  1994-11-24  |  28KB  |  615 lines
  1.   Alaska Software Inc.
  2.   Xbase/2 whitepaper                                                 (1)
  3. ------------------------------------------------------------------------
  4. _______
  5. Summary
  6.  
  7.   The Alaska Software Company was founded in August 1994 by the partners
  8.   Günter Dapprich and Steffen Pirsig. The company is based in Frankfurt
  9.   am Main. Günter Dapprich is responsible for marketing and financial 
  10.   management, Steffen Pirsig is responsible for architecture and 
  11.   technical project management.
  12.  
  13.   The aim of Alaska Software is the successful marketing and further 
  14.   development of the software development system Xbase/2. This is a 
  15.   compiler for the operating system OS/2 that possesses the same 
  16.   language capabilities as CA-Clipper under DOS, but is extended with 
  17.   many significant improvements.
  18.  
  19.   Furthermore, it is planned to extend the Xbase/2 product family under
  20.   OS/2 and also for the operating system "OS/2 for PowerPC", or WPOS, 
  21.   which will be available in 1995.
  22.  
  23.   The foundation of the company followed the completion of an alpha 
  24.   version of the development package Xbase/2. The start of the develop-
  25.   ment of the product dates back to the first quarter of 1993.
  26.  
  27. ____________________
  28. Basis of the Project
  29.  
  30.   The aim of the entire project, codenamed "SHARK", was and is the 
  31.   production of a 100% CA-Clipper 5.01 compatible development package 
  32.   for the operating system OS/2, compatible in language and function. 
  33.   See the section entitled "Compatibility".
  34.  
  35.   But source-code compatibility with CA-Clipper alone would not be 
  36.   sufficient to support the operating system OS/2. Features of OS/2 
  37.   have been imported into the product Xbase/2, which relevantly apply 
  38.   to the philosophy of a 4GL such as Xbase. A description of these is 
  39.   given in the chapter "Extended Features and Concepts".
  40.  
  41. _______
  42. Xbase ?
  43.  
  44.   Xbase is the name given to the family of languages that was invented 
  45.   by the company Ashton Tate, with their product dBase. In the last 10 
  46.   years, the language Xbase has undergone ever increasing success with 
  47.   new Xbase products such as Clipper, FoxPro, Flagship, and many others.
  48.  
  49.   The reasons for this are many-fold, the main ones being obviously in 
  50.   its high abstractness, from the  underlying architectures, as well 
  51.   as the semantic capabilities of its embedded dialog and database 
  52.   concepts.
  53.  
  54.   These both, in combination with the untyped and dynamic characte-
  55.   ristics of its language, generally describable as "tolerant", gave 
  56.   rise to the continual increase of the Xbase community.
  57.  
  58.   Today, dBase has sold 6.7 million, Clipper 2.3 and FoxPro 1 million. 
  59.   The entire Xbase market now holds more than about 10 million users 
  60.   and developers. ( Source: International Data Corp./Framingham,MA)
  61.  
  62.   Alaska Software Inc.
  63.   Xbase/2 whitepaper                                                 (2)
  64. ------------------------------------------------------------------------
  65.  
  66.   Xbase developed throughout the years to become the implementation 
  67.   language for branch-specialist and commercial applications. Thus more
  68.   and more commercial software applications under DOS are written in 
  69.   Xbase over the last decade, this mainly in CA-Clipper.
  70.  
  71.   A special market of so-called third-party products has formed around 
  72.   Xbase. This is comprised of third-party originators who have devel-
  73.   oped software products that extend the capabilities of Xbase develop-
  74.   ment packages. The number of originators of third-party products is 
  75.   hardly countable any more.
  76.  
  77.   The market for Xbase users, developers and third-party originators 
  78.   for the operating system OS/2 is not coverd, since no powerful Xbase 
  79.   package exists on the market.
  80.  
  81.   With the rapid development of the use of Xbase products, the lack of 
  82.   support for the latest arrivals in programming techniques has become 
  83.   ever increasingly obvious. Many originators of products have tried 
  84.   to help out in these shortcomings.
  85.  
  86.   Areas, where Xbase urgently requires change:
  87.  
  88.   o Consistent programming model, that allows the changeover from the 
  89.     procedural to the event-driven approach in software development.
  90.   o Object oriented programming model (OOP).
  91.   o Support of modern graphical user  interfaces ( GUI).
  92.   o Improvement of the abstraction of Xbase DML
  93.     (Database Manipulation Language).
  94.   o Disengagement of the inquiry language  from the DBF database model.
  95.  
  96.   The Alaska Software Company aims to develop an Xbase development 
  97.   package, that makes the facilities of the OS/2 operating system 
  98.   available to the Xbase developer community. 
  99.  
  100.  
  101.   Alaska Software Inc.
  102.   Xbase/2 whitepaper                                                 (3)
  103. ------------------------------------------------------------------------
  104. _____________________________
  105. Compatibility with CA-Clipper
  106.  
  107.   Xbase/2 is source-code compatible with CA-Clipper versions '86, '87 
  108.   and 5.01. A limited compatibility with most Xbase dialects such as 
  109.   FoxPro and dBase is also provided.
  110.  
  111.   The following table provides an overview of the compatibility with 
  112.   CA-Clipper:
  113.  
  114.   --------------------------------------------------------------------
  115.   Sprachumfang                CA-Clipper 5.1               Xbase/2 1.0
  116.   --------------------------------------------------------------------
  117.   Commands                               yes                       yes
  118.   Functions                              yes                       yes
  119.   Codeblocks                             yes                       yes
  120.   Objects                             (1)yes                       yes
  121.   Preprocessor directivs                 yes                       yes
  122.   Userdefined Commands                   yes                       yes
  123.   Userdefined Functions                  yes                       yes
  124.   Runtime macro-evaluation               yes                       yes
  125.   private, public, local, static         yes                       yes
  126.   dynamic Variables                      yes                       yes
  127.   Extend-System                          yes                    (2)yes
  128.   --------------------------------------------------------------------
  129.  
  130.   1) CA-Clipper only has internal objects, Xbase/2 features a complete 
  131.      object model.
  132.   2) Xbase/2's extend system has been greatly enhanced in its API 
  133.      interface capabilities, and has been made easier to handle.
  134.  
  135.   Alaska Software Inc.
  136.   Xbase/2 whitepaper                                                 (4)
  137. ------------------------------------------------------------------------
  138. ______________________________
  139. EXTENDED FEATURES AND CONCEPTS
  140.  
  141. Language Philosophy
  142.   The members of the development team are C/C++ or Lisp developers, who
  143.   have had to introduce themselves extensively to the Xbase language 
  144.   and its dialects such as especially CA-Clipper. In this way, it was 
  145.   clearly concluded that the extended capabilities of the OS/2 operating
  146.   system must be made available from the simple and tolerant level of 
  147.   the Xbase language. Thus, during the development of the Xbase/2 
  148.   compiler, the most important rule of approach was to capture all the 
  149.   complex mechanisms of OS/2 thoroughly and completely.
  150.  
  151. Maximum Values
  152.   Due to the efficient use of the mechanisms available under OS/2, there
  153.   are no bounds in Xbase/2, as in CA-Clipper under DOS. The 64k limit 
  154.   for strings, and the limit of 4096 for the number of elements in an 
  155.   array do not exist in Xbase/2. The size of any data type is mainly 
  156.   only limited by the available physical and virtual memory under OS/2.
  157.   Arrays with 100,000 elements, or a 4Mb long text can be stored in a 
  158.   single variable under Xbase/2.
  159.  
  160. Exchangeable Database Machines
  161.   Instead of using the concept of an RDD (Replaceable Database Driver) 
  162.   as used in CA-Clipper, Xbase/2 uses the concept of an abstract 
  163.   database machine (DBE: Database Engine), which is comprised of several
  164.   individual components. These components are internally objects, used 
  165.   to provide the management of data and files.
  166.  
  167.   For the time being, the architecture of the DBE components is based 
  168.   on the System Object Model (SOM1) of OS/2, and will be ported to SOM2,
  169.   as soon as this extended system object model becomes generally 
  170.   available.
  171.  
  172.   In Xbase/2, databases are dynamically loaded and embedded at runtime,
  173.   and can also be released again at runtime. This technology differs 
  174.   radically from the RDD technology used in CA-Clipper, in which mono-
  175.   lithic database drivers have to be prepared at link time, which 
  176.   requires significantly larger amounts of memory-space.
  177.  
  178.   In Xbase/2, the components (objects) of many DBE's can be joined 
  179.   together to form a new DBE. Using this modular model, for instance, 
  180.   an index can be made for a file, which is in SDF format (System Data
  181.   Format). In this case, all one needs to do is to load in the NTX 
  182.   components of the DBFNTX Database Engine, that makes it possible to 
  183.   sort files logically in SDF format.
  184.  
  185.   The Xbase/2 subsystem that makes this technology possible is the 
  186.   Database Management Language Broker (DMLB). The DMLB simplifies the 
  187.   development of Database Engines. Applications written in Xbase/2 using
  188.   DMLB as an database-access-layer can connect to a wide range of 
  189.   Database systems.
  190.  
  191.   We shall provide third party developers a special DMLB toolkit, with 
  192.   example implementations, including source-code, and the "SOM bindings"
  193.   on demand, free of charge.
  194.  
  195.   Alaska Software Inc.
  196.   Xbase/2 whitepaper                                                 (5)
  197. ------------------------------------------------------------------------
  198.  
  199. The Object Model
  200.   CA-Clipper 5.01 has four internal object classes, three of them are 
  201.   the foundation onto which the enormous flexibility of the Get-System 
  202.   and the TBrowse is based on. However, the fact that CA-Clipper lacks 
  203.   an Object-Oriented-programming model is an enormous shortcoming. In 
  204.   the development package Xbase/2, an object model exists that is 
  205.   available to the developer at language level, and provides him with 
  206.   object oriented programming as a basis for the development of complex
  207.   applications.
  208.  
  209.   As a matter of fact the Get und TBrowse  classes are usable under 
  210.   Xbase/2 as base classes, with all the facilities of object oriented 
  211.   programming ( OOP).
  212.  
  213. Xbase Parts
  214.   Any extension of the existing range of dialog components must be as 
  215.   efficient and reliable as possible, especially when it comes to third
  216.   party originators. For this reason, a special encapsulating and 
  217.   binding mechanisum was developed: the Xbase Parts,or, in short, XBP's.
  218.  
  219.   Conceptually, XBP's may be compared to technologies such as VBX 
  220.   Controls (Visual Basic) and Digitalk PARTS. Communication with these 
  221.   takes place via the Event Management available under Xbase/2, and  
  222.   the so-called "XBP Callback Slots", in which a  codeblock can be 
  223.   anchored.
  224.  
  225.   By contrast with existing concepts such as VBX Controls etc., XBP's 
  226.   are real objects, within the existing Xbase/2 object model.
  227.  
  228.   We use the term "Parts" on purpose, since the internal classes, from 
  229.   which the XBP's are derived, are modeled very closely according to 
  230.   the specifications given by OpenDoc.
  231.  
  232.   We shall provide third party developers a special XBP toolkit, with 
  233.   example implementations, including source-code, on demand, free of
  234.   charge. 
  235.  
  236. Event Model
  237.   The concepts that the "modern" graphical user interfaces, such as 
  238.   Presentation-Manager or Windows, provide for the software developer, 
  239.   are in our opinion no longer up to date.
  240.  
  241.   Quite apart from that, they are not in any way in line with the 
  242.   philosophy of a language such as Xbase.
  243.  
  244.   Thus, the "dispatching mechanisms" in Xbase/2 under OS/2 are complete-
  245.   ly encapsulated, and embedded in a flexible and easy to manage event 
  246.   model.
  247.  
  248.   The advantages of the available event model are:
  249.  
  250.   o Very easy migration of applications in charactermode
  251.     (Video Input/Output, VIO) to graphics mode
  252.     (Presentation Manager Mode, PM)
  253.   o Encapsulation of the PM specifications/restrictions
  254.     (eg. 1/10 second rule)
  255.   o Transition to OpenDoc is possible without any problems
  256.   o Significantly greater working reliability of application programs.
  257.  
  258.   Alaska Software Inc.
  259.   Xbase/2 whitepaper                                                 (6)
  260. ------------------------------------------------------------------------
  261.  
  262. Multithreading
  263.   Advantage has been taken of a particular feature of OS/2, called 
  264.   Multithreading, during the development of Xbase/2, from the beginning,
  265.   and in every stage of development.
  266.  
  267.   All operations on data types are already so well encapsulated, that 
  268.   there are no more problems that can hamper an asynchronous concurrent
  269.   use of an Xbase/2 application.
  270.  
  271.   The consequent use of the features of multithreading, in conjunction 
  272.   with the event model, described in the last paragraph, has lead to the
  273.   situation, that the Xbase/2 developer does not have to worry about the
  274.   1/10 Second rule of the PM any more.
  275.  
  276.   In Xbase/2, the developer is able to perform a calculation over an 
  277.   array of 50.000 values without having to care that interaction with 
  278.   the Workplaceshell may be interrupted.
  279.  
  280.   Automatic" threading allows XBP's, under Xbase/2, to update informa-
  281.   tion independently in a thread specially provided for themselves. In 
  282.   this way, for example, in the case of a database navigation, the 
  283.   message-command to "stabilize" is sent to the owned Browse object. 
  284.  
  285.   The developer can thus concentrate on his original targets.
  286.  
  287. Data Types and Persistence
  288.   Saving and loading of "private" and "public" dynamic variables are 
  289.   no longer supported in their proprietary rudimentary form. This 
  290.   causes a slight incompatibility with CA-Clipper.
  291.  
  292.   However, all data types are persistent in Xbase/2. This applies to 
  293.   character strings, numeric and date values, and arrays of any dimen-
  294.   sionality. All these values can be saved and loaded.
  295.  
  296.   A real special feature and advance over CA-Clipper, provided by 
  297.   Xbase/2 is the capability of saving and loading of codeblocks (The
  298.   reader can guess the consequences resulting from this in the develop-
  299.   ment of applications, particularly for data-driven applications.).
  300.  
  301. Memory Management
  302.   The architecture of the Xbase/2 runtime system makes use of a memory 
  303.   management system of its own based on handles, the efficiency of which
  304.   is brought about by a separate thread with "Packer" and "Garbage 
  305.   Collector". This elegantly solves the problem of the typical fragmen-
  306.   tation and unrecoverable loss of memory space. Additionally, another 
  307.   feature of this memory management system is the complete isolation of
  308.   Xbase/2's own internal memory management from memory requirements 
  309.   arising from C-heap functions of the "malloc-family".
  310.  
  311.   For the C developer, who wishes to provide additional functions on the
  312.   Xbase/2 language level, this means that one does not have to worry at
  313.   all about any possible interference between the two memory management
  314.   systems.
  315.  
  316.   Alaska Software Inc.
  317.   Xbase/2 whitepaper                                                 (7)
  318. ------------------------------------------------------------------------
  319.  
  320. Seamless - Rexx 
  321.   In the course of development, OS/2's interpreter or script language 
  322.   REXX became a significant tool for the development team. Important 
  323.   problems such as version control, using one single text source for 
  324.   the online help and the handbook,  were solved. Many hundred 
  325.   kilobytes of REXX scripts have been written in this time.
  326.  
  327.   The positive experience of the development team with REXX is also 
  328.   available to Xbase/2 developers and users. Any application produced 
  329.   under Xbase/2 can run a REXX script within its own address space, with
  330.   transparent access to the functions of the application and of the 
  331.   runtime system, by means of calling one function.
  332.  
  333.   In this way, all applications developed using Xbase/2 are by nature 
  334.   capable of scripting. It is now simple to import data from host 
  335.   systems, and to automize any functions of an Xbase/2 application, by 
  336.   using a Rexx script.
  337.  
  338. Mission Critical Applications
  339.   The concept of exception handling under OS/2 has been introduced via 
  340.   the language construct BEGIN/END SEQUENCE - RECOVER - BREAK, provided
  341.   by CA-Clipper. All program errors, whether they are of the runtime 
  342.   system or of OS/2 itself, are taken out as error objects of the 
  343.   language level.
  344.  
  345.   The Xbase/2 developer is thus for the first time able to provide real
  346.   mission-critical applications, for sensitive tasks in the daily use of
  347.   Xbase/2 applications.
  348.  
  349. The OS/2 Help System
  350.   The help system provided by OS/2 is supported by all dialog components
  351.   of the Xbase/2 development package. The help compiler IPFC, available
  352.   under OS/2, is also part of the development package.
  353.  
  354. What else ...
  355.   An exhaustive description of all extended capabilities of OS/2, and 
  356.   the methods of support for them provided by Xbase/2, would overrun 
  357.   the space available here. It should be mentioned, that the general 
  358.   automatic support of OS/2 facilities such as locale settings 
  359.   (Currency symbol, date format), and the ISO collation table was/is 
  360.   always guaranteed.
  361.  
  362.   Alaska Software Inc.
  363.   Xbase/2 whitepaper                                                 (8)
  364. ------------------------------------------------------------------------
  365.  
  366. Compiler Technology
  367.   We have taken particular notice of compiler technology. As a result 
  368.   of intensive study of the language, and the use of RISC and CISC 
  369.   architectures, we have decided on a "hybrid technology", which is 
  370.   certainly not one of the simplest concepts in compiler construction.
  371.  
  372.   This, stated clearly, means that the generated code in the object 
  373.   files produced by our compiler consist of a mixture of "native-code"
  374.   and "pseudo-code" (P-code). Our test cycles and analyses have
  375.   definitely shown that the best performance for a untyped dynamic 
  376.   language such as Xbase can be achieved using this technology. A 
  377.   special part of our compiler, the so-called "interferencer", 
  378.   optimizes the balance between P-code and "native code".
  379.  
  380.   However, under all circumstances, all functions, procedures, their 
  381.   context, and all flow-control operations, are always generated as 
  382.   "native code". Only the expressions themselves are balanced between
  383.   "P-code" and "native code".
  384.  
  385. 32-bit Native Code
  386.   The object files generated by the Xbase/2 compiler comply with the
  387.   "object module format" used by OS/2, and are therefore not affected 
  388.   by any further restrictions. Generally expressed: applications 
  389.   developed under Xbase/2 are real 32 Bit OS/2 2.x application programs.
  390.  
  391. Open to all sides
  392.   One of the main reasons for the success of CA-Clipper was/is the 
  393.   Extend System. For this reason, the following API documentations are 
  394.   being made available for the development package Xbase/2, which also 
  395.   provide the C/C++ developer with the possibility of accessing data 
  396.   types of the language level and running codeblocks.
  397.  
  398.   The API model of Xbase/2 consists of the following groups:
  399.  
  400.   o Parameter API
  401.   o Container API
  402.   o Memory API
  403.  
  404.   Additionally, the following toolkits are available on request to all 
  405.   interested third-party developers, free of charge:
  406.  
  407.   o XBP toolkit
  408.   o DMLB toolkit
  409.  
  410.   Alaska Software Inc.
  411.   Xbase/2 whitepaper                                                 (9)
  412. ------------------------------------------------------------------------
  413. __________
  414. Conclusion
  415.  
  416.   It is our opinion, that the development team has reached the target 
  417.   to consequently support a large number of the specific enhancements 
  418.   of OS/2, as well as giving the language Xbase, in particular the 
  419.   dialect Clipper in this case, another upward push. This being in 
  420.   particular, since for the first time a classical "midrange develop-
  421.   ment tool" is being introduced under OS/2.
  422.  
  423.   Especially as far as the support of OS/2 by Xbase products is 
  424.   concerned, there has been an enormous gap. The aim of our development
  425.   package Xbase/2 was and is to close this gap, and to show DOS and 
  426.   Windows Xbase developers, that OS/2 provides real productive
  427.   advantages.
  428.  
  429.   Furthermore, on the basis of our clear compatibility and migration 
  430.   strategy for the Xbase/2 development package, a real stimulus is 
  431.   produced, to migrate from DOS to OS/2: this being not only as a 
  432.   result of the fact that simply recompiling CA-Clipper applications 
  433.   with our development package produces a much more stable application 
  434.   program.
  435.  
  436. Views towards the Future
  437.   We obviously had many ideas during the course of the project. The most
  438.   important of these have already been observed, but not yet implemen-
  439.   ted,  in the Version 1.0 described here.
  440.  
  441.   After handing the Version 1.0 over to the maintenance and support 
  442.   teams, the development team will attempt to realize these ideas.
  443.  
  444.   At present, considerations are being proposed to split the 
  445.   development package Xbase/2 into different product lines. The 
  446.   version 1.0 will form the basic technology: ie. all future products 
  447.   will be based on the same codebase: Xbase/2 version 1.x.
  448.  
  449.   o WPS-based integrated development environment, based on SOM2 and DSOM
  450.     This can contain Class Browser, Editor with Generic Complete, and 
  451.     Compiler-frontend, which extends incremental compilation. This all 
  452.     being not in the usual way, but based on a repository-oriented 
  453.     technology. For this, further research is still necessary, 
  454.     especially in the areas of "repository", "Version Control" and 
  455.     "Concurrent Project Management".
  456.  
  457.   o WPS-based interactive user front end, in which source code is either
  458.     interpreted, or run after compilation. This would be like a classic
  459.     user-oriented Xbase system, such as "dBase for Windows" and such 
  460.     like.
  461.  
  462.   o Since the front end of our compiler technology is already inter-
  463.     changeable in the Version 1.0, 100% support of dBase and FoxPro 
  464.     dialects of Xbase would be an additional possibility.
  465.  
  466.   Alaska Software Inc.
  467.   Xbase/2 whitepaper                                                (10)
  468. ------------------------------------------------------------------------
  469.  
  470.   o Extension of the compiler and OOP model with support for 
  471.     Direct-to-SOM, that is, that classes in the Xbase/2 language level 
  472.     may derived from classes encapsulated in SOM (eg. Workplaceshell
  473.     classes). Additionally, classes implemented in Xbase/2 can be used 
  474.     as base classes in other languages, which are supporting SOM 
  475.     usage-bindings. In this way, a large step towards distributed 
  476.     applications in combination with DSOM would be possible.
  477.  
  478.   o The areas of OpenDoc, OpenScriptingArchitecture (OSA semantic 
  479.     events), has very much fascinated us, and you can be sure, that we 
  480.     shall also in this area be amongst the first  to provide these 
  481.     mechanisms for developers in Xbase/2
  482.  
  483.  
  484.   Alaska Software Inc.
  485.   Xbase/2 whitepaper                                                (11)
  486. ------------------------------------------------------------------------
  487. ____________
  488. Availability
  489.   As always, the availability of a product is the most important point.
  490.   In this point, we have gone according to the policy of keeping the 
  491.   entire project completely secret.
  492.  
  493.   This white paper is first issued together with the beta announcement,
  494.   in October 1994. The beta program is itself limited to our complied 
  495.   range of about 100 firms. We expect to reach this number of beta 
  496.   subscribers in December 1994.
  497.  
  498.   We are not placing any limit on the duration of the beta test. The 
  499.   product will be announced as available as soon as the beta test has 
  500.   attained our target results. These are:
  501.  
  502.  
  503. Beta Drop 1
  504.  
  505.   o Report the completeness of functions and features of our product
  506.  
  507.   o Report the actual level of compatibility with Clipper 5.01, and 
  508.     any changes required to obtain this compatibility.
  509.  
  510.   o Correct errors/bugs
  511.  
  512.   o Any necessary correction of documentation, and elimination of 
  513.     ambiguities.
  514.  
  515.  
  516. Beta Drop 2
  517.  
  518.   o Test the installation program
  519.  
  520.   o Report internal values of load-up, and other metric information 
  521.     of our compiler technology and run-time system.
  522.  
  523.   o Validation of the various optimizing strategies
  524.  
  525.   o General increase of performance.
  526.  
  527.  
  528.   We should like to draw attention to the fact, that the final contents
  529.   of our Xbase/2 product package will be fixed after completion of 
  530.   Beta-Drop-1.
  531.  
  532.  
  533.   Alaska Software Inc.
  534.   Xbase/2 whitepaper                                                (12)
  535. ------------------------------------------------------------------------
  536. ___________________
  537. Further Information
  538.  
  539.   We hope to have provided some insight into our product, and our 
  540.   present plans, with this whitepaper.
  541.  
  542.   More detailed information about the technical details of the Xbase/2
  543.   development package can be found in the information brochure "Xbase/2:
  544.   Concepts and Technology", which will be released and available at 
  545.   the end of the Beta Test. You can obtain this free of charge from 
  546.   the following sources.
  547.  
  548. Specializing Journalists
  549.   Specializing journalists may subscribe to our press service as 
  550.   distributors free of charge. Any test orders for our product can be 
  551.   obtained via our press service.
  552.  
  553. Distributors
  554.   Distributors who would like to distribute our product, should please 
  555.   contact our product marketing department.
  556.  
  557. Third Party Originators
  558.   Add-on originators and developers who wish to produce a third party 
  559.   product for Xbase/2, may request further information. They should 
  560.   make a point of contacting our 3P (Third Party Product Program).
  561.  
  562. Technical Support
  563.   We have decided on CompuServe as our official support channel. 
  564.   We shall provide the forum OS2UGER with an own section: Xbase/2. 
  565.   Furthermore, all Xbase/2 development packages will include a 
  566.   CompuServe brochure, which gives the registered Xbase/2 user the 
  567.   right to obtain a $15 user credit and a temporary ID within 
  568.   CompuServe.
  569.  
  570.  
  571.   Alaska Software Inc.
  572.   Xbase/2 whitepaper                                                (13)
  573. ------------------------------------------------------------------------
  574. _________________
  575. How to Contact us
  576.  
  577.   Alaska Software GmbH.,
  578.   Henschelstraße 26,
  579.   60314 Frankfurt/Main
  580.   Germany
  581.   Telephone:    + 49 -69 -439646
  582.   Fax:          + 49 -69 -439673
  583.   CompuServe:   100436,1375
  584.   Internet:     100436.1375@compuserve.com
  585.  
  586.   Product Marketing:     Günter Dapprich
  587.   Info/Press Service:    Hanna Cano
  588.  
  589.   Your Xbase/2 development team
  590.  
  591. ___________
  592. Trade Marks
  593.  
  594.   PC-DOS, OS/2, Workplace Shell and Presentation Manager are registered
  595.   trademarks of International Business Machines Corp.
  596.  
  597.   SOMObjects and System Object Model (SOM) are trademarks of 
  598.   International Business Machines Corp.
  599.  
  600.   MSDOS, FoxPro and Visual Basic are registered trademarks of 
  601.   Microsoft Corp.
  602.  
  603.   dBASE is a trademark of Borland International Inc.
  604.  
  605.   Flagship is a trademark of Multisoft GmbH.
  606.  
  607.   CA-Clipper, Visual Objects for Windows are registered trademarks of 
  608.   Computer Associates International Inc.
  609.  
  610.   OpenDoc is a registered trademark of Apple Computer Inc.
  611.  
  612.   Smalltalk and PARTS are trademarks of Digitalk Inc.
  613.  
  614.   Xbase/2, DMLB and XBP are trademarks of Alaska Software GmbH.
  615.