Platform independent applications

We work very hard at SCS at maintaining platform-independence in our applications, and we have a long history of this. Years ago, we delivered systems on DEC equipment running RSX, RSTS and VMS; HP equipment running MPE; and IBM equipment running MVS. More recently, we have delivered systems running under SCO Unix® and Linux. During the last 30 years, we have supported at least 40 different platform types and versions. We ported the advertising applications to various flavors of Windows as well (most recently Windows 7 and Windows 8 with touch), but only Layout-8000 has been requested on that platform. Our editorial and digital asset management products are Windows applications, although, even there, the image and story files may be archived on a Linux server.


Why do we remain platform-independent?

Most of the advertising front-end systems in the 1980s were completely bound to specific hardware and operating systems, and they paid the price when new options became available. Can you imagine rewriting an entire application written in DEC assembly language and tuned to a specific DEC operating system? It just didn’t happen! Systems written specifically for Tandem machines, IBM AS400s and HP3000s died out too. And - here’s the lesson in all of this - systems written specifically and exclusively for Windows and Oracle® will someday go too. It’s not that any of these environments were or are intrinsically bad (although some have been better than others); it’s just that they come in and out of favor. Why bind your applications so tightly to any one of them?


How do we stay platform-independent?

In the early history of our company, we did it by using the standard subsets of high-level languages (e.g. Pascal) rather than anybody’s assembly language or non-standard extensions to high-level languages. Then all we had to do was find a compiler for the language on a new platform and, perhaps, translate some control scripts. This seems so obvious now, but there were people who claimed that only with assembly language could you get the performance required for a large multi-user system. We always felt that the right algorithms and database design were much more important for good performance than any tweaking at the machine level, and we have never had performance issues. Over time we became convinced that the best way to keep ourselves platform independent was to create the set of development tools that we use now for all of the applications we build ourselves (i.e., the entire advertising system suite). Only the tools need to be ported to new platforms; every application written with the tools then moves without recoding. Not only platform changes but changes to the look and feel of every application are implemented by enhancements to the tools. Our WIMPS interface (windows, icons, menus, pointers and scroll bars) is now as pretty as anyone’s.


What are these tools?

We call them, collectively, Spice (the Dune books and movie were a big hit when a name was being chosen). They include a screen designer, relational database manager, text editor, composition engine, dialog manager, help manager, application code/formula language, XML processor, report writer and charting package. Back when this was a buzzword, we called Spice a 4th generation language. The term is used to refer to non-procedural (or declarative) high-level languages built around database systems. SQL, for example, is a 4th generation language (the first generation was machine language, the second was assembly language and the third included high level procedural languages like Pascal or C).


What is the underlying database?

We use a record manager called C-tree (developed by Faircom, www.faircom.com). We are free to modify the source code, and we have made some enhancements over the years. It provides an ODBC-compliant (Open Data Base Connectivity) interface to our databases, which allows any report writer or query language that is ODBC-compliant to read our Spice databases directly and independently. Crystal Reports® and Visual Basic®, for example, can access Spice’s ODBC-compliant databases. Spice also supports mirroring its databases with others like PostgreSQL. Our Spice report writer (SpiceRAQ) can give you access to all the data in a Spice database - as a printed report, a screen display or an exported text file. (This is in addition to all the standard and user-customizable reports that come with each application.) No one wants to feel that his or her enterprise data - an extremely valuable resource - could ever be held hostage by a vendor who uses a “proprietary” database package. Our customers have never been in this position. We have customers who send data to a “data warehouse” or interface to or from applications from other vendors; sometimes they create these interfaces themselves using the report writer tool and sometimes they ask us to help them do it. Our ODBC-compliant database interface tool makes data access easy for Crystal Reports experts.


What platform(s) do we use ourselves?

Linux is our primary development platform here at SCS. Many of us also have Windows PCs and/or Macs on our desks, but a lot of SCS staff get along just fine with a Linux desktop. We all have access to Linux servers to develop and/or test the SCS applications and to use some of our own in-house databases. We don’t feel the need to go completely “Microsoft-free,” but it would be possible. We have some customers who have made that a goal, and our applications could help them.


Why should you feel comfortable doing business with SCS even if we are “different”?

For one thing, we’ve been serving the newspaper business for a long time (for our company’s history, read “About SCS” on our web site. In fact, we’ve outlasted most of the newspaper vendors that were around when we started, even the industry leaders. I like to think that’s because we have been doing things right. (As a side note, we were founded one year before Oracle and just one year after Microsoft.) We’re not going away anytime soon, and even if we did, we have our application source code in escrow for our customers. We’re committed to the best algorithms that computer science, newspaper expertise and brainpower can provide. We have skilled programmers implementing these algorithms. Customers praise our support staff as the best anywhere. Our long-term technological vision, our dedicated and intelligent staff, our extensive experience in both computers and newspapers and our reliable support are just a few of the reasons to get your newspaper systems from SCS.

For many years, SCS was a reseller of the Scoop editorial system developed by SCOOP Publishware, AB in Sweden. In 2017, we purchased the rights to the system (then called Scoop 5) and its source code from Ulf Wilkenson, the CEO. Ulf also sold his entire company to a former 25% partner, Juha Siintola, owner of Mediabox Oy in Finland.

SCS embarked on a nearly complete rewrite of Scoop 5 using up-to-date software technology and adding many new features.  We are calling the result Scoop 7.

The Scoop 7 rewrite is coming to completion as planned.  The recovery cost exceeded several hundred thousand dollars.   Yet Scoop 7 retains the easy fluid workflow of Scoop 5 that customers loved.

Jussi  supplied development resources focused on plugins for the newest versions of InDesign.  SCS focused on the rest, including replacing operating systems, databases,  user interface libraries, etc.  Scoop 7 now closely inter-operates with SCS's advertising systems.

Neither party will compete with the other.   SCS's territory is the Western Hemisphere and MediaBox's is the rest of the world.