11/20/93: RE: MM/1 Production Re: Msg 82897 by Delphi, | Category: Delphi - General Information | 76 comments - (Comments are closed)

RE: MM/1 Production Re: Msg 82897

83230 20-NOV 22:22 General Information
RE: MM/1 Production (Re: Msg 82897)
From: MREGC To: JOELHEGBERG

Joel,

> Would people pay attention to the standards?

Well, in order for me to follow any standard I would have to consider it to
be at least as good as the method I would use should the standard not exist,
and it would have to be as easy to implement.

For example, quite awhile ago I was designing another GUI for the MM/1,
(this was before I decided that having yours and Mike’s available was enough.)
Chet Simpson and I were working on our own “standard” for MM/1 icons, and had
talked Mike into revising Desktop to conform to it. Unfortunately we never
completed it. It supported variable sized icons, animated icons, shadowed
icons, icons which included sound, and some other things. Now say there was a
standards committee and they decided on a standard for all OSK GUI icons. If
that standard did not include EVERYTHING that our icon format did ,(and if I
was still developing this GUI,) then I wouldn’t even give it a second glance.

The problem with standards is that they sometimes have the tendency to
cater to the lowest common denominator. For OS9 that might mean developing
standards which would have to be useable on a terminal. That would be
unacceptable. This in a way describes my biggest fear about the MM/1 users
adopting G-Windows as our standard. I don’t know enough about GW to be sure
but the fear is that software would be written so that it could run on the
least capable system possible, like DOC programmers writing software so that
the 8088, or at least the 286 would be required to run it. (Oops, make that
DOS programmers!) Since there are a number of systems out there whose graphic
abilities can surpass the MM/1 that wouldn’t be a big deal, but what about
sound? If you wrote Write Right! for G-Windows would it still have the ability
to use a variety of sounds, like that pleasing chime? This is a small example,
but its often the small things that make a program a winner. Most importantly,
as I understand it, G-Windows really needs the highest res screen to run, and
I’ve been told that it doesn’t support lower res screens. *IF* this is true
then I couldn’t use it to write for the MM/1′s 256 color modes. Also
unacceptable.

Standards should give the ability to create portable software, but they
shouldn’t prevent, or even discourage programmer’s use of each machine’s
unique special capabilities.

…Eric…

76 comments to RE: MM/1 Production Re: Msg 82897

  • pucc_unknown

    83240 21-NOV 07:48 General Information
    RE: MM/1 Production (Re: Msg 83230)
    From: CBJ To: MREGC

    I agree on points about standards but threre are reasons to implement them as
    well. While you as a programmer may not use them in every case IF there is a
    set of standard ways to do things you will likely follow them when possible.
    You can also develop a “standard program” and add the bells and whistles to
    specific versions for platforms that can support them. A Standards committee
    need not be confined or delegated to programming eother. There is a proposal
    for one and until I get more info I’ll keep an open mind about it.
    Carl

  • pucc_unknown

    83264 21-NOV 21:46 General Information
    RE: MM/1 Production (Re: Msg 83230)
    From: DSRTFOX To: MREGC

    Eric, G windows requires at least 400×600 screen resolution to run, so you
    shouldn’t have a problem there! It also supports higher resolutions IF
    available.

  • pucc_unknown

    83291 23-NOV 01:04 General Information
    RE: MM/1 Production (Re: Msg 83230)
    From: NIMITZ To: MREGC

    Eric, if you wish to have standards you can live with, help write them!

    My goal is, not only to help adopt new standards, but to bring some old
    ones that will help us out to OS9. So, watch this space, you’ll probably see
    a mix of old and new, that hopefully make sense to all of us (well, at least
    most of us! ) ;)

    David

  • pucc_unknown

    83297 23-NOV 03:16 General Information
    RE: MM/1 Production (Re: Msg 83291)
    From: MREGC To: NIMITZ

    > Eric, if you wish to have standards you can live with, help write them!

    David, as you can see I am never at a loss for an opinion or a way in
    which to express it. If there is online discussions about these proposed
    “standards” then you will be sure to see input from me.

    …Eric…

  • pucc_unknown

    83341 24-NOV 06:32 General Information
    RE: MM/1 Production (Re: Msg 83291)
    From: SCWEGERT To: NIMITZ

    > Eric, if you wish to have standards you can live with, help write them!
    >

    David, am I missing something? Didn’t we go through this a year and a half ago
    with pitiful results?

    I would think we need to put our efforts behind more applications (standard
    or not) first to help us decide wether or not we have a market for which to
    write a standard!

    *- Steve -*

  • pucc_unknown

    83255 21-NOV 19:42 General Information
    RE: MM/1 Production (Re: Msg 83240)
    From: MREGC To: CBJ

    > You can also develop a “standard program” and add the bells and whistles
    > to specific versions for platforms that can support them.

    This is very true. The question is, how many programmers will do this, and
    how many will stop at the “standard program”? Not to say I would blame a
    programmer for doing so, since customizing various versions for the different
    machines might prove to take too much time and not be financially beneficial
    to said programmer. Customizing a program to the system which the programmer
    owns would be much easier to code and to test, and might be less apt to happen
    should the programmer be writing a standard version.

    …Eric…

  • pucc_unknown

    83272 22-NOV 02:16 General Information
    RE: MM/1 Production (Re: Msg 83264)
    From: MREGC To: DSRTFOX

    > G windows requires at leas 400×600 screen resolution to run…

    Yes, but my question was, will it support the MM/1 LOWER resolution of
    320 x 200 in 256 colors? If it doesn’t then It’ll only be of limited use to me.

    ..Eric…

  • pucc_unknown

    83275 22-NOV 15:51 General Information
    RE: MM/1 Production (Re: Msg 83255)
    From: CBJ To: MREGC

    The point is that it is strictly up to you as a programmer to decide whether
    you’ll add the bells and whistles. There are many programs that were written
    on another platform and OS that give you options for graphics (CGA, EGA, VGA,
    etc.) I think you get my drift. If you use the lowest common denominator then
    some functions are not available to you but you can still run the bare program.
    The point is the bells and whistles were added because they help sell a product
    to the higher end crowd but the main program is designed to sell to everyone.
    Carl

  • pucc_unknown

    83295 23-NOV 03:09 General Information
    RE: MM/1 Production (Re: Msg 83275)
    From: MREGC To: CBJ

    > If you use the lowest common denominator then some functions are not
    > available to you but you can still run the bare program. The point is the
    > bells and whistles were added because they help sell a product…

    True. But consider this possibility. In orer to convince the few people in a

    smaller market to buy your program you have to put in all the bells and
    whistles you can. Expand hat market through use of a cross-platform windowing
    system, and maybe you can sell enough copies of the more bare program without
    having to add all the bells and whistles in for each version of the program and
    still turn a hefty profit without all the extra work.

    Now, of course this is only a possibility. The one factor that could
    completely invalidate the argument is competition. If the expanded market
    creates competition then each programmer will have to make his program as good
    as possible in order for it to survive. But in oir marketplace, what’s the
    odds of sch a competitive struggle taking place? (I really need to do
    something about all these typos!) Hopefully I’m wrong, but I’d say slim and
    none.

    ..Eric…

  • pucc_unknown

    83300 23-NOV 03:52 General Information
    RE: MM/1 Production (Re: Msg 83272)
    From: AJMLFCO To: MREGC

    I am using G-Windows. It will display Gif’s that are 320x200x256,
    I believe. At least it has displayed most every resolution I
    have tried so far. I don’t know how the 320×200 would look
    for the entire desktop, though. It might look a little
    rough.

    Allen

  • pucc_unknown

    83315 23-NOV 20:03 General Information
    RE: MM/1 Production (Re: Msg 83300)
    From: DSRTFOX To: MREGC

    According to Steve Adams (G-Windows writer), the desktop needs at least 600×400
    to display properly. It will display the lower res graphics also though.

  • pucc_unknown

    83334 24-NOV 02:52 General Information
    RE: MM/1 Production (Re: Msg 83300)
    From: MREGC To: AJMLFCO

    > I don’t know how the 320×200 would look for the entire desktop, though.

    Actucally I wasn’t referring to running the desktop in that mode. I agree
    that it needs the max resoulution. I was just wondering if the G-library
    supports a standard set of screen resolutions compatible with every platform,
    or if it supports every res/colors combination of the particular machine its
    being run on.

    > I am using G-Windows.

    Good, then you can answer a question which recently came to mind. Does
    G-Windows support some kind of clipboard standard? If so, and I guess you
    would have to have the developer’s pack to know this, how comprhensive of a
    standard is it?

    …Eric…

  • pucc_unknown

    83342 24-NOV 07:39 General Information
    RE: MM/1 Production (Re: Msg 83297)
    From: NIMITZ To: MREGC

    Thanks. We need a great deal more discussion here, and also some basic
    agreement on the way to go. But the market place will always enforce it’s
    opinion, even if it doesn;t have one
    !

  • pucc_unknown

    83344 24-NOV 07:46 General Information
    RE: MM/1 Production (Re: Msg 83341)
    From: NIMITZ To: SCWEGERT

    Steve,

    Part of the functions of the standards organization that I envision
    wouuld be helping to get the programs right the first tiem. And I am willing
    to go trough this every month if I have to to make it happen. What efforts
    are going forth for new ap
    plications now?? Very little. And Very Slow. Too little too late spells
    disaster. It is time to fix that once and for all. We waste too much time on
    the development of routines that are available as libraries for DOS and UNIX
    and don’t spend enough
    t time on the things that make a program distinctive. So, this is a
    development gain as much as anything else.

  • pucc_unknown

    83396 26-NOV 22:58 General Information
    RE: MM/1 Production (Re: Msg 83341)
    From: THETAURUS To: SCWEGERT

    >>I would think we need to put our efforts behind more
    applications (standard or not) first to help us decide whether or not
    we have a market for which to write a standard!

    I agree. Somewhere down the road, standards for Professional OS9
    will most likely be a necessity for the community, but not unless
    there is software to apply them too. The programmers need to get the
    programs out first. I know that is easier said then done, with the
    amount of programmers available now, but one way or another it needs
    to be done. Hopefully sometime in the future when the OS9 User’s Group
    is in full swing, it will be able to help push that software
    developement somehow.
    >Chris<

  • pucc_unknown

    83359 25-NOV 03:01 General Information
    RE: MM/1 Production (Re: Msg 83342)
    From: MREGC To: NIMITZ

    As you seem to be promoting some more graphically inclined features of the
    MM/1, I think one of the first things that should be done is that the MM/1
    programming community needs to get together and figure out what windowing
    system were going to support, and then develop and/or agree on some standards
    for window useage, such as a clipboard standard, an icon standard, a filepicker
    standard (such as the one Mike includes in the C library), a sound standard
    (there are several out there, which one should we use?), amd an animation
    standard. THEN we can worry about developing some general cross-platform OSK
    standards.

    …Eric…

  • pucc_unknown

    83389 26-NOV 20:42 General Information
    RE: MM/1 Production (Re: Msg 83359)
    From: NIMITZ To: MREGC

    Actually, Eric, I see no reason to delay general cross-platform OSK
    standards for KWindows programmers sakes. I’m concerned in this context for
    ALL OSK users. In fact, I’m working on getting Kevin Darling to write some
    docs
    for KWindows that would allow standards development, nor is he insensitive to
    the issue. But you have some good ideas, sen dmyd em your real name and
    address, so
    I can add you to a list of particilpants??

  • pucc_unknown

    83517 29-NOV 00:48 General Information
    RE: MM/1 Production (Re: Msg 83359)
    From: AJMLFCO To: MREGC

    Eric,

    I hope you don’t think I am picking on you by replying
    to several of your messages in a row here. It’s just that
    you have brought up a couple of interesting concepts….

    I wonder about a “
    der about the wisdom of a “standards” effort here.
    I say this because the group that frequents this forum
    and even the other forums represent a very tiny percentage
    of the total customer base for OS9 and OSk products. Are you
    going to set standards for CD-I? Industrial users? Telecommunications?
    Embedded systems? Etc, Etc…

    First, get the User’s Group built up and include more than
    50 to 100 hobbyists in it. When you have a representative
    group of paid professional programmers on board, then we can
    consider talk of standards. I suspect we don’t know what
    the “market” is yet. Let’s research that first. Lets get
    more OS9 users from all areas involved in the User’s group
    first.

    Allen

  • pucc_unknown

    83408 27-NOV 04:31 General Information
    RE: MM/1 Production (Re: Msg 83389)
    From: MREGC To: NIMITZ

    > I see no reason to delay general cross-platform OSK standards for
    > KWindows programmers sakes.

    I think just maybe we need to get our own house in order before setting out
    to cure the whole community’s ills. I’m not talking KWindows programmers here,
    I’m talking *MM/1* programmers, (granted these 2 groups may be one and the
    same.) I just think it wouldn’t be to our benefit to devote time to
    developing windowing standards for say GWindows when the MM/1 group might
    decide to stay behind KWindows.

    Promoting the advancement of OSK *is* important to me, but I own an MM/1,
    and promoting it is what’s most important to me.

    The personal info you requested is forthcoming.

    …Eric…

  • pucc_unknown

    83428 27-NOV 16:56 General Information
    RE: MM/1 Production (Re: Msg 83408)
    From: NIMITZ To: MREGC

    Eric, I’m talking about the personal OSK market as a whole. And certainly
    we need to get our act together, though that concerns hardware production
    more than anything. But by addressing certain needs of the general market
    simultaineously, we gain more input and faster development.

    David

  • pucc_unknown

    83429 27-NOV 17:00 General Information
    RE: MM/1 Production (Re: Msg 83396)
    From: NIMITZ To: THETAURUS

    Chris, the if the standards come out WITH the applications then we won’t
    have to redevelop everything later………

  • pucc_unknown

    83444 28-NOV 03:32 General Information
    RE: MM/1 Production (Re: Msg 83428)
    From: MREGC To: NIMITZ

    > I’m talking about the personal OSK market as a whole. … by addressing
    > certain needs of the general market simultaneously, we gain more input and
    > faster development.

    Understood. And a very good point. I just don’t want to be out fixing the
    “OSK market as a whole” while our own little part of that market is in disarray.

    I also wonder, “faster development” of what? If its generic, vanilla, cross-
    platform OSK programs with no flair, then I’m really not concerned. But if its
    powerful, windowed, maximized for each specific machine software, well then now
    you’re talking! If we can take care of our own problems and the communitiy’s at
    the same time, then all the better. Count me in.

    On a side note, in discussing software standards, there is one thing that’s
    severely disappointed me with the MM/1 software so far. And may I first state
    that *I am also very guilty of doing this same thing!* We have a windowing
    system with windows capable of being moved and resized. While many programs
    out allow you to move them, I can’t think of any that let you resize them. I
    had thought that, when writing the stuff I’ve done, that because my programs
    needed the full screen to work in, that it would be of no use allowing the
    user to resize it. However, this is far from true, just look at the windowing
    systems of other computer’s out there. Windows can be resized for easy storage
    on the screen, and you could also use the scrollbars to scroll across the full
    window display.

    And before anyone says it, let me first respond to the obvious argument
    against what I’m saying. “Under OS-9 you have multiple screens and therefore
    you don’t need the ability to move or resize windows, when you can just hot-key
    from screen to screen.” Well, I happen to like having multiple windows of
    varying sizes on one screen. The operating system supports it, so why shouldn’t
    our programs let us do it? In particular, terminal programs and text editors.
    It would be sensible for me to shrink my term program to say, 5 lines, and store

    it at the top or bottom of the screen so I could keep an eye on the text
    capture that I’m doing of the message base while I’m also editing some code in
    my somewhat shrunken text editor window. As it stands right now, I don’t think
    the MM/1 has the programs which would allow me to do that. What a waste.

    As a programmer I’m vowing to include resizeability into any *new* software
    that I develop from here on out, and as a user I’m now demanding, (ok,
    demanding is a little strong, I’m asking,) that any software I purchase from
    here on out give me the flexibility that I wish for and that the operating
    system easily supports.

    End of sermon. Opposing arguments may start … now.

    ..Eric…

  • pucc_unknown

    83460 28-NOV 13:22 General Information
    RE: MM/1 Production (Re: Msg 83444)
    From: FHOGG To: MREGC

    GWindows allows moving and resizing windows without the application having to
    do anything.

    This should/could be added to KWindows rather than individual applications.

    Just a thought… Hope I don’t get pounced on for making it.

  • pucc_unknown

    83465 28-NOV 14:33 General Information
    RE: MM/1 Production (Re: Msg 83444)
    From: JOELHEGBERG To: MREGC

    Eric,

    > state that *I am also very guilty of doing this same thing!* We have a
    > windowing system with windows capable of being moved and resized. While
    > many programs out allow you to move them, I can’t think of any that let
    > you resize them. I had thought that, when writing the stuff I’ve done,

    Actually, I can think of quite a few that let you resize them, although
    most are just small utilities. I try to add resizing to all my
    utilities and small games (Othello, GClock, StrMan, ViewFax, etc.), and
    yes, the next version of Write-Right will even allow this. :)

    > be of no use allowing the user to resize it. However, this is far from
    > true, just look at the windowing systems of other computer’s out there.
    > Windows can be resized for easy storage on the screen, and you could also
    > use the scrollbars to scroll across the full window display.

    For some things, it’s not bad (like text apps), but for some graphics
    apps, it’s very hard, since if your virtual screen is larger than your
    displayed screen, and you have to FFill a region that resides partly on-
    screen and partly off-screen, I think you can see the problem. All the
    windowing systems I’ve seen keep track of virtual screens for the
    programmer, but K-Windows does not yet support this feature. I don’t
    believe graphics programmers should spend their time trying to support
    virtual windows, since that is something that needs to be supported in
    the windowing system itself. However, graphics that can be rescaled to
    fit in varying window sizes should be supported, like the programs I
    mentioned in the previous paragraph do.

    — Joel Mathew Hegberg.

    Delphi : JOELHEGBERG
    GEnie : j.hegberg
    Internet : JoelHegberg [at] delphi [dot] com

  • pucc_unknown

    83471 28-NOV 16:49 General Information
    RE: MM/1 Production (Re: Msg 83444)
    From: COLORSYSTEMS To: MREGC

    When the cgfx.l library has all of the nexessary code for handling
    resizing, dynamic scoll bars and all that other stuff which is done by
    the OS in MS-Windows, then I’ll take advantage of them in any new program
    I write.

    ————————————
    Zack C Sessions
    ColorSystems

    “I am Homer of Borg, prepare to be assimi … OOOOHHH, DOUGHNUTS!”

  • pucc_unknown

    83537 29-NOV 21:42 General Information
    RE: MM/1 Production (Re: Msg 83444)
    From: NIMITZ To: MREGC

    Eric,

    My idea it that if programmers share development of those parts fo a program
    that
    are essentially the same regardless of display system, then we acelerate
    development across the board. IE – several developers develope a DBase IV
    compabtible file library, and a DBASE language interpreter. They then
    seperately use these components to
    develop competing products. One is standard TTY, the other may be Termcap or
    termlib compatible, and others may be based on GWindows ro KWindows. But the
    products are there for consumers, to speed system sales, which then speeds
    software sales, and pay
    s you to upgrade the program.

  • pucc_unknown

    83473 28-NOV 18:11 General Information
    RE: MM/1 Production (Re: Msg 83471)
    From: EMTWO To: MREGC

    As others have said, while you can do some moveing and resizeing under
    Kwindows, its not exactly user-friendly to do so. The K-Windows has some
    problems dealing with ‘windows’ that are recieveing output. You can’t
    resize a window when thats happening. Other programmers have had to deal
    with other aspects of K-Windows that need work. Until then, the only
    real reason to have 19 different tiny windows on one screen is because
    you only HAVE one screen. K-Windows at least handles that nicely.

  • pucc_unknown

    83481 28-NOV 20:04 General Information
    RE: MM/1 Production (Re: Msg 83471)
    From: MREGC To: COLORSYSTEMS

    > When the cgfx.l library has all of the necessary code for handling
    > resizing, dynamic scoll bars and all that other stuff which is done by the
    > OS in MS-Windows…

    First, I’d really like to know what you mean by “necessary code”, since
    K-Windows allows you to resize, and find out what the new window size is, I
    don’t think anything else is “necessary”, helpful, but definitely not
    necessary.

    Second, I’ve written my own dynamic scrollbars routines before, and it
    really didn’t take much time or effort to do so. Mike has also done this in
    his get_dir routine, and he didn’t find it very hard either. I realize some
    of the code involved in writing for resizeable windows is long and complicated,
    but dynamic scrollbars isn’t one of those things.

    Finally, I agree that it would be nice if the windowing system handled more
    of the work, but I don’t think its realistic for us to expect our windowing
    system to be quite as dynamic as MS-Windows. After all, as we’re all quite
    aware, we arn’t exactly in the mainstream here, and what Kevin/the new KW
    programmer got/will get out of their efforts falls FAR short of what the
    Microsoft programmer got for his efforts. In our market, the programmer is
    simply goig to have to work a little harder, its a fact of life we have to live
    with, unless we institute David Graham’s idea of writing this code and
    incorporating it into libraries available to everyone. As Joel pointed out,
    resizing support is available in several programs. Those programmers didn’t
    find it an impossible task, why should the rest of us? (Myself included)

    …Eric…

  • pucc_unknown

    83476 28-NOV 19:37 General Information
    RE: MM/1 Production (Re: Msg 83460)
    From: MREGC To: FHOGG

    > GWindows allows moving and resizing windows without the application having
    > to do anything. … Just a thought… Hope I don’t get pounced on for
    > making it.

    Of course not Frank. Information dispensation is always a good thing as far
    as I’m concerned. In fact, it answers a question which I’d had about GWindows.
    Tell me, when you shrink a GWindow, does GW allow the use of the scrollbars to
    scroll around the virtal full screen? Also, can the programmer use the
    scrollbars to scroll around an area larger than full screen? If bth of these
    are possible, what happens when say, your program uses the scrollbars to scroll
    across a sheet of music which is actually several screens long, but when the
    user shrinks the program window, GW wans to use the scrollbars to scroll
    around the virtual full screen. Which one wins out?

    Hope I made that example clear enough. If you’re not sure what I mean, just
    shout.

    ..Eric…

  • pucc_unknown

    83528 29-NOV 06:08 General Information
    RE: MM/1 Production (Re: Msg 83460)
    From: JEJONES To: FHOGG

    > GWindows allows moving and resizing windows without the application having
    > to do anything.

    Are you saying that if I resize a window in which I have, say, umacs or less
    running, and in the former case then type ^l (redraw screen) or the latter
    type space (display next screenful), that they will display appropriately
    for the new window size?

    *** posted w/InfoXpress 1.1 ***

  • pucc_unknown

    83478 28-NOV 19:48 General Information
    RE: MM/1 Production (Re: Msg 83465)
    From: MREGC To: JOELHEGBERG

    Joel,

    > Actually, I can think of quite a few that let you resize them…

    You’re right, and in fact I’ve seen most of these, I guess I was just
    thinking about the bigger apps and these just slipped my mind. :)

    > and yes, the next version of Write-Right will even allow this. :)

    Good! You know that’s something I was looking for. Keep up the good work.

    > … but for some graphics apps its very hard.

    Oh I’m well aware of that. In fact, twice in the last 2 – 3 years I’ve
    tried to start discussions on how we should handle the virtual screen
    scrolling thing, but no one was interested. Now it looks like we’re ready to
    talk anout it. Even though it wouls still be nice, I can understand if say a
    game doesn’t support it, as most games wouldn’t even be written to run in a
    window, (I’m writing one right now and I know I’m not even thinking about
    trying to have it run in a window, much less one that can be resized.) But
    there are just some things, (term progs, word pros, DBs, etc…) that should
    be done in resizeable windows, and the extra code to handle scaling the text
    output to the window size just wouldn’t be that much.

    ..Eric…

  • pucc_unknown

    83480 28-NOV 19:57 General Information
    RE: MM/1 Production (Re: Msg 83476)
    From: FHOGG To: MREGC

    Eric,

    > when you shrink a GWindow, does GW allow the use of the scrollbars
    > to scroll around the virtal full screen?

    Yes it does. As a matter of fact the scroll bars are proportional to
    the amount of the window you are looking at. By that I mean that by
    looking at the scroll bar area you can see about what size the actual
    window is compared to what you are looking at. (There must be an
    easier way to say this)… whatever… it’s pretty neat.

    > Can the programmer use the scrollbars to scroll around an area larger
    > than full screen? etc etc

    I >think< so??? You determine the size of the virtual window and the
    size of the actual window when you open it. (Even where it appears
    on the screen) I don’t have the docs here to really answer you.
    Perhaps someone else who is using GW can answer that and the other
    question.

    Frank

  • pucc_unknown

    83521 29-NOV 04:49 General Information
    RE: MM/1 Production (Re: Msg 83476)
    From: PAGAN To: MREGC

    >when you shrink a GWindow, does GW allow the use of the scrollbars to
    >scroll around the virtal full screen?

    Yes. You can also write to any part of the screen whether it’s displayed or
    not and the screen can be set up to automatically buffer whatever is written
    or drawn to it.

    >can the programmer use the scrollbars to scroll around an area larger
    >than full screen?

    Again, Yes. There is an upper limit on the size of a screen. For normal,
    buffered text (terminal emulation) the limit is (I think) 160 columns by 96
    rows. I don’t know what the upper limit for non-emulation screen is but
    it’s at least two or three times teh size of my screen (800 X 600).

    >If bth of these are possible, what happens when say, your program uses the
    >scrollbars to scroll across a sheet of music which is actually several
    >screens long, but when the user shrinks the program window, GW wans to use
    >the scrollbars to scroll around the virtual full screen. Which one wins
    >out?

    Hmmmmm. Never tried this but, based on experience with other aspects of the
    windowing system, I’d say itwould probably be up to the application which
    would ‘win out’. Since G-Windows will, if instructed, notify an application
    whenever a scroll event occurs, the program can decide how it wants to treat
    it. If the application or user changes the visible section of the virtual
    screen, G-Windows will automatically update the scroll bars.

    Stephen (PAGAN)

  • pucc_unknown

    83577 30-NOV 05:02 General Information
    RE: MM/1 Production (Re: Msg 83476)
    From: EDELMAR To: MREGC

    Eric,

    To answer a couple questions you have raised regarding G-WINDOWS.

    In an earlier message to Allen (AJMLFCO), you asked whether G-WINDOWS
    could support images, etc. of resolutions other than that currently in use.
    The answer is yes. Example – suppose you are in a 800x600x256 mode. You
    can view any image of 800x600x256 or less in its entirety on the screen. If
    the image is 320x200x16, it will simply use only a portion of the screen -
    slightly less 25% and not use the full CLUT. If the image is larger, say
    1024x768x256, than most of it will appear on the screen. Using the horizontal
    and vertical scroll bars, you can view other portions of the image. However,
    if the image uses more than 256 colors, say some of the newer 24 bit stuff,
    G-WINDOWS will return an error message informing you it doesn’t not know how
    to display the image. G-WINDOWS can only handle 256 colors maximum. Caveat -
    not all implementations of G-WINDOWS can handle 256 colors. Some of the
    implementations are for 16 colors and it is possible to do a 2-color port
    (monochrome), also. Of course, these implementations cannot display 256
    color images, either.

    When you open most windows in G-WINDOWS, a ‘draw buffer’ (the G-WINDOWS term
    for what has been called ‘virtual window’ here) is also created. Most of
    the time, it is the same size as the maximum size of the window. Even if
    you resize the window so it is smaller, the draw buffer remains the same size.
    This permits the user to ‘scroll’ through the draw buffer to view its
    contents. It also permits writing to a portion of the window which may
    not be selected for viewing.

    When an application is written for G-WINDOWS, it can take advantage of the
    ‘auto draw buffer’ capability. I did this when I wrote ‘VIEW FAX’ for Joel
    Hegberg’s ETHAFAX which I showed in Atlanta. While most faxs are of a speci-
    fied width, they can vary in length. Rather than attempt to create a worst-
    case draw buffer (very wasteful of memory), I used the ‘auto draw buffer’
    capability. The size of the buffer is determined by the incoming data and is
    independent of the window size. A side note on this – it is possible to
    scale the image to view the entire message on one screen. However, some
    information/detail may be lost especially if the scaling ratio is high as
    might be required for some of the lower resolution implementations of
    G-WINDOWS.

    You asked whether G-WINDOWS supports some kind of a ‘clipboard standard’.
    I’m not sure what you mean. If you are referring to clip-art, a conversion
    routine for GIF files does come with G-WINDOWS. And, I’m working on conver-
    sion routines to convert most of the other popular gfx formats to G-WINDOWS
    format. Along this line, I’ve finished a conversion routine to convert HPLJ
    soft fonts to G-WINDOWS format and will do one for TRUE-TYPE soft fonts later.

    Ed Gresick – DELMAR CO

  • pucc_unknown

    83482 28-NOV 20:10 General Information
    RE: MM/1 Production (Re: Msg 83473)
    From: MREGC To: EMTWO

    See my message 83481 to Zack.

    As Joel has pointed out, several programs out there do support resizing.
    It is true that for some programs, the extra code needed to do so would be
    almost overwhelming, especially if you run into K-Windows problems. But for
    many program, supporting resizing would not be all that much of a
    Herculean effort. With all the current talk about us developing mainstream
    quality software, I think making this extra effort will be a must.

    …Eric…

    Opinions expressed herein are never guaranteed to meet with public approval. :)

  • pucc_unknown

    83486 28-NOV 20:52 General Information
    RE: MM/1 Production (Re: Msg 83478)
    From: MRGOOD To: MREGC

    Doesn’t cgfx.l 5 have a text scaling function? I could swear I
    saw something about that in the documentation.

    Hugo

  • pucc_unknown

    83512 29-NOV 00:06 General Information
    RE: MM/1 Production (Re: Msg 83334)
    From: AJMLFCO To: MREGC

    Eric,
    I don’t know the specific answers to your questions
    about G-Windows clipboard standards or supported
    resoulutions as I don’t have the Developer’s package.
    I think a text file describing all of the (at that time)
    supported “C” functions is in the OSk database here.

    Allen

  • pucc_unknown

    83518 29-NOV 01:06 General Information
    RE: MM/1 Production (Re: Msg 83480)
    From: AJMLFCO To: FHOGG

    Frank,
    Yes you can use Gwindows to scroll across an object larger
    than even a full screen! I have a 1024×768 Gif that I can
    view using the HGwindows scroll bars. It’s about two CRT’s
    wide by about 1-1/2 CRT’s high. ( should have been Gwindows above,
    not HGwindows..ughh).

    I had a couple of local OS/2 users over last week.
    They liked a lot of what they saw in Gwindows. There
    are some similarities between OS/2 Presentation
    Manager and Gwinidows, BTW.

    Allen

  • pucc_unknown

    83566 30-NOV 02:49 General Information
    RE: MM/1 Production (Re: Msg 83480)
    From: MREGC To: FHOGG

    > (There must be an easier way to say this)

    Don’t worry, Frank, I understand exactly what you mean. Its the same kind
    of scrollbars that I mentioned that I, Mike Haaland, and I think one or two
    others have already been using, except that we each had to write our own
    code to handle them.

    Thanks for the info.

    …Eric…

  • pucc_unknown

    83538 29-NOV 21:58 General Information
    RE: MM/1 Production (Re: Msg 83517)
    From: NIMITZ To: AJMLFCO

    Allen, first off, the professional programmers you speak of need a reason to
    join. A standards group is one sort of thing that could draw them. Secondly,
    the ‘hobbyists’ you speak of include people interested in makeing a living
    selling OS9 hardware and software. It includes people interested in BUYING OS9
    stuff. What makes you think these people alone aren’t worth an effort to
    develope standards. You
    know, standards are incredibly easy to meet if you have none. And that is a
    major weakness of OS9. We don’t aim for the stars, so we end up shooting
    ourselves in the foot!!

  • pucc_unknown

    83570 30-NOV 03:05 General Information
    RE: MM/1 Production (Re: Msg 83517)
    From: MREGC To: AJMLFCO

    > I hope you don’t think I am picking on you…

    Don’t worry. I had expected this talk to spawn some actual arguments,
    (which I wouldn’t have minded one bit,) but its actually been very civil and
    intellectual.

    > I wonder about the wisdom of a “standards” effort here.

    If you’ve been following this conversation then you know it developed
    because I was expressing an apprehension about this idea of developing
    standards. Though I think with the right ideology behind it
    it could be a positive thing.

    …Eric…

  • pucc_unknown

    83547 29-NOV 22:39 General Information
    RE: MM/1 Production (Re: Msg 83518)
    From: FHOGG To: AJMLFCO

    > Yes you can use Gwindows to scroll across an object larger
    > than even a full screen!

    Actually I did know that… really I did… honest.

    I like to hear when OS2 or ‘other’ people like GWindows.
    Tell me more.

    Frank

  • pucc_unknown

    83548 29-NOV 22:39 General Information
    RE: MM/1 Production (Re: Msg 83528)
    From: FHOGG To: JEJONES

    > Are you saying that if I resize a window in which I have, say, umacs
    > or less running, and in the former case then type ^l (redraw screen)
    > or the latter type space (display next screenful), that they will
    > display appropriately for the new window size?

    Yes. The resized window is uh… a window that you are looking thru to
    the stuff under it. ummm does that explain it?

    Frank

  • pucc_unknown

    83669 2-DEC 00:36 General Information
    RE: MM/1 Production (Re: Msg 83528)
    From: AJMLFCO To: JEJONES

    re: 83528

    Unfortunately, GWindows is more like OS/2 or MS-Windows
    where the text is cropped when the window is smaller than the text
    display. You have to scroll right/left/up/down to view it.
    Desqview/X has “scalable fonts” which re-size to suit the
    window—neat but a load on the cpu (otherwise known as slow).
    Once DV/X get the fonts re-scaled, things go quick, though.
    It might be possible for the programmer to detect the window
    size in Gwindows and adjust to one of the three loaded “Qfonts”
    on the fly. I don’t have the developer’s kit so I can’t
    check that out.

    Allen

  • pucc_unknown

    83567 30-NOV 02:51 General Information
    RE: MM/1 Production (Re: Msg 83486)
    From: MREGC To: MRGOOD

    > Doesn’t cgfx.l 5 have a text scaling function?

    Not that I remember, though I could be wrong.

    …Eric…

  • pucc_unknown

    83568 30-NOV 02:52 General Information
    RE: MM/1 Production (Re: Msg 83512)
    From: MREGC To: AJMLFCO

    Thanks, I’ll look for it.

    …Eric..

  • pucc_unknown

    83572 30-NOV 03:29 General Information
    RE: MM/1 Production (Re: Msg 83521)
    From: MREGC To: PAGAN

    Very imprssive. GWindows is starting to look better by the minute.
    Unfortunately, I keep hitting that cost of the development system wall.

    …Eric…

  • pucc_unknown

    83573 30-NOV 03:32 General Information
    RE: MM/1 Production (Re: Msg 83537)
    From: MREGC To: NIMITZ

    It would be good to se your idea come to life, but I think it will be
    awhile before we see this market suuport several programs of the same type
    on different platforms on the same computer. Maybe we should start with some
    slightly easier goals. :)

    …Eric…

  • pucc_unknown

    83574 30-NOV 03:39 General Information
    RE: MM/1 Production (Re: Msg 83567)
    From: JOELHEGBERG To: MREGC

    > > Doesn’t cgfx.l 5 have a text scaling function?
    >
    > Not that I remember, though I could be wrong.

    It does have scaletext() (I believe that’s what it’s called), but it’s
    very difficult to control in some instances. I explored using it in my
    page preview routine for Write-Right!, but after a few tests, I wrote my
    own code. :)

    — Joel Mathew Hegberg.

    Delphi : JOELHEGBERG
    GEnie : j.hegberg
    Internet : JoelHegberg [at] delphi [dot] com

  • pucc_unknown

    83579 30-NOV 07:25 General Information
    RE: MM/1 Production (Re: Msg 83548)
    From: JEJONES To: FHOGG

    > Yes. The resized window is uh… a window that you are looking thru to
    > the stuff under it. ummm does that explain it?

    I think so, but IMHO, if I understand what you’re saying, it’s not the
    behavior I’d personally like to see. What I’d like to see is this:

    I have a shell running in a window, and at the shell prompt I type

    less woof.c

    For some reason, while less is in mid-run, I decide to resize the
    window. After I resize the window, if I type space at the less
    running in the window, I want less’s notion of what another
    “screenful” of woof.c is to reflect *the number of lines displayed
    in the resized window*.

    This takes work; what it really means is that less has to be notified
    of the change and potentially change, for example, the value of its
    TERMCAP environment variable. Alas, it probably means that some signal
    would have to be dedicated to the purpose and a list of programs
    interested in being notified of window size changes be kept somewhere.

    Opinions expressed herein are those of their respective authors, and
    not necessarily those of any organization.

    *** posted w/InfoXpress 1.1 ***

  • pucc_unknown

    83586 30-NOV 12:02 General Information
    RE: MM/1 Production (Re: Msg 83538)
    From: CBJ To: NIMITZ

    >We don’t aim for the stars, so we end up shooting ourselves in the foot!!
    *
    Well said!!
    =carl

  • pucc_unknown

    83663 1-DEC 23:59 General Information
    RE: MM/1 Production (Re: Msg 83538)
    From: AJMLFCO To: NIMITZ

    I especially liked your comment about “We don’t aim for the
    stars, so we end up shooting ourselves in the foot!!”. How
    true, especially for those whose goal is to emulate the way
    MS-DOS does it! Instead of trying to make our systems
    leading edge, many try to just copy DOS applications.

    Allen

  • pucc_unknown

    83615 1-DEC 00:02 General Information
    RE: MM/1 Production (Re: Msg 83577)
    From: MREGC To: EDELMAR

    Thanks, Ed.

    Remember, the more information you dispense on GWindows finer attributes
    the closer I get to breaching that “cost of GWindows + cost of developer’s
    package” barrier that currently prevents me (and I’m sure som others)
    from committing to the MM/1 port.

    …Eric…

  • pucc_unknown

    83620 1-DEC 00:27 General Information
    RE: MM/1 Production (Re: Msg 83579)
    From: FHOGG To: JEJONES

    Jim,
    One of the demos that comes with GWindows (called ‘boxes’ I think)
    does just that. When you resize the window the demo changes to fit.
    I guess this means that you could do what you want in a text window.
    But as it comes up it just shows you a piece of the window when you
    make it smaller. Ahhh another thing to play with. Actually I think
    I like your comments. It would be rough reading some things that
    are formatted for 80 chars tho, like a dir -e.

    Frank

  • pucc_unknown

    83638 1-DEC 05:51 General Information
    RE: MM/1 Production (Re: Msg 83579)
    From: EDELMAR To: JEJONES

    James,

    > less woof.c

    > For some reason, while less is in mid-run, I decide to resize the
    > window. After I resize the window, if I type space at the less
    > running in the window, I want less’s notion of what another
    > “screenful” of woof.c is to reflect *the number of lines displayed
    > in the resized window*.

    What you want to do can be done but ‘less’ (and any other applications
    you want to respond as you describe) would have to be re-written. ‘less’
    and most (all?) programs that access ‘termcap’ or other files to obtain
    size (and other) information, do so only once – when the program is first
    started.

    When a window is resized, a signal is sent (actually an ‘event’) and the
    new window size is available. It is possible to write a ‘wrapper’ for ‘less’
    and other apps that would send specific information to the apps when certain
    events occur. Of course, the apps would have to be able respond to this
    information. The problem is not one of G-WINDOWS but rather, the apps.
    Apps could be written and/or modified so they can run in either ‘native’ mode
    or under G-WINDOWS and take advantage of G-WINDOWS capabilities. I suspect a
    real ambitious programmer could write an application running under native
    mode, G-WINDOWS and K-WINDOWS, at least for text based stuff without
    requiring different versions for each .

    Ed Gresick – DELMAR CO

  • pucc_unknown

    83652 1-DEC 20:54 General Information
    RE: MM/1 Production (Re: Msg 83573)
    From: NIMITZ To: MREGC

    Perhaps the different platforms won’t be on the same computer. Thats the
    advantage of OS9. And I do not think this is that hard of a goal. All
    it takes is some commitment and brain sweat.

    z

  • pucc_unknown

    83666 2-DEC 00:17 General Information
    RE: MM/1 Production (Re: Msg 83638)
    From: KSCALES To: EDELMAR

    Hi, Ed (and James, too) -

    > > For some reason, while less is in mid-run, I decide to resize the
    > > window. After I resize the window, if I type space at the less
    > > running in the window, I want less’s notion of what another
    > > “screenful” of woof.c is to reflect *the number of lines displayed
    > > in the resized window*.
    >
    > What you want to do can be done but ‘less’ (and any other applications
    > you want to respond as you describe) would have to be re-written.
    > ‘less’ and most (all?) programs that access ‘termcap’ or other files to
    > obtain size (and other) information, do so only once – when the program is
    > first started.

    Sigh. Quoting from my messages 15737/8 on the CIS OS-9 forum (July/92),
    which were replies to Kevin D’s request for input on K-Windows:

    “c) Signals when window changed: I would like to see codes similar to
    _ss_dcon() and _ss_dcoff() to enable and disable sending of a signal to
    a process when its window has been changed/resized (default, no signal,
    of course). It would have been really nice (and easy) to have been able
    to put support for these in my “sc” and “ispell” ports.”

    As far as I know, these haven’t been added. So the K-Windows programmer
    must keep checking the current window size to see if it has changed.

    > When a window is resized, a signal is sent (actually an ‘event’) and the
    > new window size is available.

    Using events (G-Windows) is a much tidier approach. Neat.

    It should be pretty simple to make a resizable G-Windows version of ‘sc’,
    so that the spreadsheet changes to reflect the resized window size.
    (The original source already understands the Unix SIGWINCH signal.)

    > Of course, the apps would have to be able respond to this information.

    Right. And if there were a simple method of managing it, I am sure more
    programmers would build it into their applications. So, how many more
    orders do you need to proceed with the MM/1 G-Windows port?

    … / Ken
    ————————————————————————–
    Ken Scales Delphi:KSCALES Internet:kscales [at] delphi [dot] com CIS:74646,2237

  • pucc_unknown

    83676 2-DEC 20:16 General Information
    RE: MM/1 Production (Re: Msg 83663)
    From: NIMITZ To: AJMLFCO (NR)

    Allen, my aim it to duplicate DOS file structures, and , in some cases,
    programming languages, while retaining features that take advantage of OS9.
    And, then, we can attract people who want simultaineously developed superior
    features, and that will allow us to acheive some penetration into the small
    business market.

    David

  • pucc_unknown

    83677 2-DEC 20:28 General Information
    RE: MM/1 Production (Re: Msg 83669)
    From: EDELMAR To: AJMLFCO (NR)

    Allen,

    In a standard ‘shell’ window, (the one you see when you start G-WINDOWS,
    use cntl-s or the menu to start new windows) you can have only one of the
    three quick fonts. The window file manager reads the environment file
    to determine which size font to use. The window is sized accordingly.

    In a ‘custom’ window, (one which runs an app written under G-WINDOWS),
    the programmer or, if he allows, the user may select any of the fonts
    in the FONTS directory or any of the quick fonts. This may be done on
    the fly. You may have different faces, styles, sizes – whatever is available
    and suits your fancy. Some of the software we’re writing permits all of the
    above plus hierogliphics or handwriting if you chose. Currently, I’m working
    on a set of fonts which will contain ‘clip-art’ for inclusion in documents.

    Ed Gresick – DELMAR CO

  • pucc_unknown

    83687 2-DEC 23:14 General Information
    RE: MM/1 Production (Re: Msg 83429)
    From: THETAURUS To: NIMITZ

    >>Chris, then if the standards come out WITH the applications
    then we won’t have to redevelop everything later………

    Well that is a good point. I just don’t know if we would be
    starting too early in the game. Maybe starting out with a set of
    standards as a foundation, and then as more software is developed,
    adding to that set as we go along might be the right idea? Is that
    what you are saying? The thing I’m thinking about right now is, at
    this point we can probably think of a few standards that will most
    likely need to be set anyway, so yes, we could take care of those
    right off the bat. While I’m not personally as informed with this
    stuff as those of you using OSK, a few things come to my head. One is
    deciding what directories would be expected to be found on a hard
    disk so we could get some of the common
    directories standardized. I still believe programs should be flexible
    enough so that the user can place them and other files in whatever
    directory they please, but the author should also have standard
    default directories he can use to start with, while allowing the user
    to put things wherever he wants with a configuration program. This
    will allow easy startup as well as flexibility. Another idea is to
    have all the machines keep the same Keyboard setup so that all the
    keys, including and especially function keys will equal the same thing
    on all machines and Kwindows environment can do it their way>. I don’t know if this
    is already taken care of, so I just mentioned it just in case. I think
    it would be a good idea to get a graphics library developed and
    distributed with OSK, similar to GFX2, for Basic. I understand once
    the MM/1 is back in production, BGFX will be getting finished up. That
    will be great, but I think there should probably be something similar
    distributed with OSK, so it will be easier to develop Basic programs
    that will run on all machines with basic>. Then comes the subject of Termcaps,PrintCaps and all that
    other stuff I don’t really know anything about. I guess the committee
    would decide what goes into the termcap files, but then again, maybe
    termcaps is fine as is. I only mentioned it because I’ve heard a lot
    about it, especially it seems, when standards are discussed. Would
    this also be the time to decide on what Windowing systems should be
    considered ‘standard’ system>? I remember being in conference a short while back with Steve
    Rottinger who was explaining to me about API’s and how it is used in
    the Clone and I guess Mac world. I never heard about such a thing
    before that, but it sounds like a killer idea. It would be better to
    just have something like that, which sounds like a Graphics Termcap,
    which will run any program in whatever GUI you wish. Would such a
    thing likely be developed in the not too distant future, or would it
    be a MAJOR programming effort? I still don’t know much
    about it, so if there is more to it please let me in on it ;-)
    I think after a small base is developed, and as more software
    comes out, people will be able to think of more standards that will
    need to be set. It just sad that we will probably have more software
    standards than software for sometime
    >Chris<

  • pucc_unknown

    83713 3-DEC 20:58 General Information
    RE: MM/1 Production (Re: Msg 83666)
    From: EDELMAR To: KSCALES

    The magic number is 10. I have 10 orders – need 10 more.

    Ed

  • pucc_unknown

    83717 3-DEC 21:07 General Information
    RE: MM/1 Production (Re: Msg 83687)
    From: NIMITZ To: THETAURUS (NR)

    That is pretty much it. Start out with basic functionality and progress
    forward, as MS-DOS is doing in it’s pursuit of UNIX…. ;)

  • pucc_unknown

    83739 4-DEC 04:17 General Information
    RE: MM/1 Production (Re: Msg 83687)
    From: EDELMAR To: THETAURUS (NR)

    Chris,

    I don’t believe this commuity is ready (mature enough) to establish standards.
    However, we might consider something along the line of ‘recommended practices’.

    I won’t try to address all the points you made; some are very good but others
    assume (almost) identical hardware.

    > One is deciding what directories would be expected to be found on a hard
    > disk so we could get some of the common directories
    > standardized.

    MW distributes Professional OS-9 with a recommended directory structure.
    Most OEM’s conform to this. Tandy didn’t in the CoCo.

    > Another idea is to have all the machines keep the same Keyboard setup so
    > that all the keys, including and especially function keys will equal the
    > same thing on all machines > Gwindows and Kwindows environment can do it their way>.

    Not really necessary. We have termcap to take care of this problem. Besides,
    I don’t think you’d be able to convince the terminal mfgs they should conform.
    G-WINDOWS does not define the output of the keyboard. This is determined
    by the OEM of the machine.

    > I understand once the MM/1 is back in production, BGFX will be getting
    > finished up. That will be great, but I think there should probably be
    > something similar distributed with OSK, so it will be easier to develop
    > Basic programs that will run on all machines > doesn’t come with basic>.

    Whether assembler, C or Basic, gfx are peculiar to the specific hardware.
    As things stand now, there isn’t anyway to get a single verions of ‘BGFX’
    to work across all the platforms. However, if the OEM’s would get together,
    It just might be possible to come up with something like a GFX termcap as
    you suggest. However, to keep the speed up, it would probably be better
    to attach it to the kernel; i.e., each hardware implemenation would have
    a P(n) attached to the kernel peculiar to that implementation. It would
    respond to a standard set of gfx calls.

    > Would this also be the time to decide on what Windowing systems should be
    > considered ‘standard’ > system>?

    I don’t believe the UG would be able to make such a recommendation nor do
    I believe they should. This is one area the market should be left to make
    the decision.

    I think the ‘standards committee’ must be very careful in what it does.
    It does not represent the entire OS-9 community.

    Ed Gresick – DELMAR CO

  • pucc_unknown

    83726 3-DEC 21:38 General Information
    RE: MM/1 Production (Re: Msg 83713)
    From: HAWKSOFT To: EDELMAR

    Hi Ed!
    !—————————————————————————–!
    !HAWKSoft check# $dead !
    !244 S. Randall Rd. #172 !
    !Elgin, Il. 60123 !
    ! !
    !pay to the order of DELMAR $200.00 !
    !TWO HUNDRED and no/sense ——————————————-DOLLARS !
    ! !
    !memo G-Windows MM/1 signed Christopher R. Hawks !
    !—————————————————————————–!

    Here’s my check! Sign me up!!

    :-> :-> :-> :-> :-> :-> :-> :-> :-> Chris < -: <-: <-: <-: <-: <-: <-: <-:

  • pucc_unknown

    83728 3-DEC 21:46 General Information
    RE: MM/1 Production (Re: Msg 83726)
    From: MITHELEN To: HAWKSOFT (NR)

    Hey Chris, that is ALMOST a legal check, you forgot to put the date on it
    though…

  • pucc_unknown

    83738 4-DEC 04:16 General Information
    RE: MM/1 Production (Re: Msg 83676)
    From: EDELMAR To: NIMITZ (NR)

    David,

    > Allen, my aim it to duplicate DOS file structures, …

    What is the advantage of the DOS file structure vs the OS9 file structure?
    From experience, I can assure you the OS9 file structure is more robust
    than DOSs. If you need to read/write DOS disks, we already have PCF provided
    by MW.

    > … in some cases, programming languages, …

    Today, most DOS apps are written in one of the flavors of ANSII C or C++.
    We have Ultra-C for OS9 and OS-9000. It is ANSII compliant and the latest
    version appears pretty solid. What other programming languages would you add?

    > .. that will allow us to acheive some penetration into the small business
    > market.

    I don’t see how languages or file structures will help. We need the gp
    aps. Otherwise, this is a tough nut to crack – I’ve tried – unsuccessfully.
    Only sold 2 POS systems using OS9. However, I’ve sold many running under
    UNIX – but these were not ‘mom-pop’ operations, either.

    Before trying for this market, I’d suggest you look at the software already
    being offered. For example, Real World puts out a package which starts at
    a few hundred dollars. As more capability is needed, the user can buy
    additional modules. When he is ready to expand, he can go into networking
    or UNIX – still under Real World. Incidently, Real World and some of their
    competitors put out some very good packages, provide excellent support and
    can point to the many thousands (hundreds of thousands?) of satisfied users.
    One other point you should consider; most small businesses, when selecting
    their software package, will seek the advice of their accountant. Your
    ultimate data structure will have to conform to what they use. For what its
    worth, I’ve found it easier to compete against IBM, NCR, WANG and the other
    providers of more sophisticated and expensive software/hardware (but not
    necessarily better) than the likes of Real World, etc. who service the small
    business user.

    If we’re to compete in the general MSDOS/UNIX market, aside from the obvious
    gp programs, I think we need the capability of importing/exporting files to
    the more popular MSDOS/UNIX programs. Most have some sort of proprietary
    compression/data structure.

    Ed Gresick – DELMAR CO

  • pucc_unknown

    83899 9-DEC 22:16 General Information
    RE: MM/1 Production (Re: Msg 83739)
    From: THETAURUS To: EDELMAR

    >>…we might consider something along the line of ‘recommended
    practices’.

    After reading the rest of your message and a couple others, I
    kinda like that idea. I’m not quite informed enough to understand the
    whole picture, but recommended practices will probably go over better
    for now, untill the OS-9 world is ready for concrete standards.

    >>MW distributes Professional OS-9 with a recommended directory
    structure. Most OEM’s conform to this. Tandy didn’t in the Coco.

    Thanks for the info. I didn’t know MW did that since I am only on
    Level II. That takes care of that question. Maybe the UG could just
    publically endorse that structure so that others in the now young
    personal market will work with it course>.
    >Chris<

  • pucc_unknown

    84178 19-DEC 10:27 General Information
    RE: MM/1 Production (Re: Msg 83739)
    From: CBJ To: EDELMAR

    You make many good points here especially about the UG not representing the
    whole community. I do feel the need to point out that in other areas it is
    rapidly becoming the norm for Standards committes to begin working on a
    standard that isn’t even in production yet. I would call that a most immature
    market. I don’t think that the maturity of the market is what is important, I
    think rather that knowing what the real market is and where it is headed is
    much more important. I don’t think the UG is ready to start setting standards
    just because we don’t have a true representation of the true OS9 market. This
    is something we need to address.
    -Carl

  • pucc_unknown

    83925 11-DEC 02:14 General Information
    RE: MM/1 Production (Re: Msg 83738)
    From: AJMLFCO To: EDELMAR

    Let me put in a pitch for a needed program, if one
    were to want some small business sales–
    A relational database with multiuser simultaneous
    access to the files. Use OS9′s record locking or
    build on it to come up with something better. It
    would become a “killer” workgroup application if
    it was :
    -relational
    -able to import/export to Dbase III+ file format
    -totally GUI (Gwindows)
    -networkable via TCP/IP NFS
    -some support for VT100 terminals if you really have to.
    -SQL support
    -extensible with C language

    I don’t want much, huh?

    Allen

  • pucc_unknown

    83935 11-DEC 04:24 General Information
    RE: MM/1 Production (Re: Msg 83925)
    From: EDELMAR To: AJMLFCO (NR)

    Allen,

    > Let me put in a pitch for a needed program, if one
    > were to want some small business sales– …
    .
    .
    .
    > I don’t want much, huh?

    Just for you, I took 5 minutes and whipped one up .

    Actu sell such a program. It’s called SCULPTOR and comes from MPD in
    England. Does most everything you’ve asked for except it isn’t ‘totally GUI’
    but it does run under G-WINDOWS and you can have different SCULPTOR programs
    running in different windows. I use it under G-WINDOWS and will normally
    have 4 to 6 programs sitting there ready to use.

    It is relational, will support just about any terminals you want, includes
    SQL and can be networked. Utilities are available to import/export to
    several ‘foreign’ databases and/or you can import/export via ASCII files.
    A library is available to permit you to extend it with C if you wish.

    You can develop your app on one platform and take the compiled code (actually
    an intermediate code) and run it on about 100 or more other platforms/OSs
    without re-compiling the code. Datafiles are equally transportable.

    Interested?

    Ed Gresick – DELMAR CO

  • pucc_unknown

    83950 11-DEC 12:44 General Information
    RE: MM/1 Production (Re: Msg 83925)
    From: COLORSYSTEMS To: AJMLFCO

    What you are asking for would require on the order of man YEARS to accomplish.
    Considering that all MM/1 developers are single person operations, I seriously
    doubt if anyone of them would be willing to tackle such a large project.
    OTOH, if some DOES, you are right, it WILL be a killer product!! One which *I*
    certainly would purchase!

    ————————————
    Zack C Sessions
    ColorSystems

    “I am Homer of Borg, prepare to be assimi … OOOOHHH, DOUGHNUTS!”

  • pucc_unknown

    83954 11-DEC 15:46 General Information
    RE: MM/1 Production (Re: Msg 83950)
    From: NIMITZ To: COLORSYSTEMS

    Zack, that is one reason that I suggested that some MM/1 developers should
    sell their development packages commercially, to save those man hours and
    years. It is also the reason I suggest that the OS9 Standards organization
    sponsor development teams to bring other systems standards to OS9 in library
    and subroutine form. These
    applications are possible, in timely fashion if we work together where possible.

    David

  • pucc_unknown

    84058 15-DEC 02:43 General Information
    RE: MM/1 Production (Re: Msg 83950)
    From: AJMLFCO To: COLORSYSTEMS (NR)

    You are right if all you consider is the MM/1 or
    the computer I am using, or others in the personal
    market. Fortunately, or unfortunately, they amount
    all together to 1% of OS-9 usage. On the other hand,
    it might be worthwhile developing for G-Windows, which is
    used on all kinds of systems. A database might be
    a real useful addition to a system running ControlCalc
    as a reporting and data reduction tool for a
    data aquisition system. If it also is useful
    for us personal users, so be it.

    If the OS-9 users group included more commercial
    and industrial users, they might be able to set
    me straight on this.

    Allen

  • pucc_unknown

    83958 11-DEC 16:42 General Information
    RE: MM/1 Production (Re: Msg 83954)
    From: COLORSYSTEMS To: NIMITZ

    > Zack, that is one reason that I suggested that some MM/1 developers
    > should sell their development packages commercially, to save those man
    > hours and years.

    What do you mean by “development package”?

    ————————————
    Zack C Sessions
    ColorSystems

    “I am Homer of Borg, prepare to be assimi … OOOOHHH, DOUGHNUTS!”

  • pucc_unknown

    83961 11-DEC 18:51 General Information
    RE: MM/1 Production (Re: Msg 83958)
    From: NIMITZ To: COLORSYSTEMS

    libraries of commonly used subroutines, in this context.

    x

  • pucc_unknown

    84056 15-DEC 02:24 General Information
    RE: MM/1 Production (Re: Msg 83935)
    From: AJMLFCO To: EDELMAR

    Tell me more about Sculptor. I can only ask my
    questions from the framework of my own experience,
    so bear with me here. I have used Informix a bit.
    It has a couple of lines across the top of the
    screen with options. I can’t remember for sure
    but it seems there was a “ace” report writer for
    writing simple quick reports. More involved
    quiries were done with SQL programs which had to
    be created with an editor. Other options were
    a screen generator, etc. All in all, pretty
    “stone age”. I was able to impress my friends
    because I could create simple SQL routines using
    a text editor. Another package I have used is
    Dbase III+ ( haven’t upgraded to IV yet). The
    user interface to this was a lot easier because it had
    a menuing interface so I could pick options,
    create databases, short reports, browse,
    append, edit, etc. without using a text editor.
    Dbase III+ is trailing edge technology, but it
    works and is friendlier than the version of
    Informix I saw.

    A modern database system should be graphical.

    One should be able to create forms, input screens,
    and such through the GUI. The database should be able
    to create and use various windows as need for these purposes.

    So, where does Sculptor fall into all of these
    ramblings?

    Allen