HDTenEightyP/NetNews huggingface dataset:
From: mssmith@afterlife.ncsc.mil (M. Scott Smith)
Subject: Re: Direct screen writing; getting to (x,y)
Organization: The Great Beyond
Date: Tue, 12 Jan 1993 08:18:50 GMT

Juri -- thanks for the information.

> If SCR_X is indeed the width of the display, you will run into trouble
> with most Macintosh video cards. If it's the same as row_bytes, then
> things should be almost ok.

   I re-wrote the function I posted so that I don't think it uses SCR_X
anymore.  Well, here's the new one:

I do the following when I init the program:

  for (y=0; y<=(*screen_len_y); y++)
    line[y] = ((*row_bytes) * y);

And here's my PlotPoint function:

void PlotPoint(long x, long y, long color)
{
  *(char *)(base_addr + x + line[y]) = color;
}


   That avoids the use of SCR_X (and also seems to be about 1.5 times quicker
than my original version); does this avoid the problem you mentioned?  I'd
like this to be as compatible as possible with all video configurations,
including bit depth.  What would be the easiest way to handle different
bit depths?  My primary concern for now is 8-bit.

> Of course, it doesn't really work. It only works on some hardware, but
> it will cause big problems with a lot of machines.

   Is my new routine a bit more friendly, or does it still have a problem?

> As I said earlier, the keys to compatibly do direct video writes are:
>
>     SwapMMUMode
> and ShieldCursor

   I haven't messed with ShieldCursor before, so I'll look into that.  I
assume I should be calling SwapMMUMode in my PlotPoint function, right
before and after I do the plot.  Does this eat up much processor time?
It seems if I'm plotting hundreds of points, then making those hundreds of
calls might have a performance penalty.  But I don't know.  (And I guess
it's necessary in some cases anyway.)

> This works as long as no one changes the screen resolution suddenly. It
> usually doesn't happen, but I think it's possible under some circumstances.

   Someone would do that??  How rude.  :)  Would the best strategy be to
periodically check the depth of the screen you're working with, like in the
event loop, and then to do whatever's necessary if the bit depth suddenly
changes?  (Like maybe put up a dialog that say "hey, don't do that!", or
re-compute everything.)

Well, thanks for all of your information.  It was very helpful.

M. Scott Smith
  (mssmith@afterlife.ncsc.mil)

Newsgroups: comp.sys.mac.programmer
From: Matt Slot <fprefect@engin.umich.edu>
Subject: Re: Uniquely identifying a Mac? How?
Organization: University of Michigan, CAEN
X-Useragent: Nuntius v1.1
Date: Wed, 6 Jan 1993 00:50:12 GMT

If you need to do this from an application, there are several tricks you
can try. Use  TickCount() to get a long, try Random() (one in 4 billion
chance of duplication), or the
initialization time of the Boot volume.
 
Not foolproof, but pretty good.
 
Matt
From: dswartz@redondo.sw.stratus.com (Dan Swartzendruber)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Boolean type as parameter (THINK C 5)
Date: 8 Jan 1993 18:51:54 GMT
Organization: Stratus Computer, Software Engineering
NNTP-Posting-Host: redondo.sw.stratus.com


Are you sure caller and callee define int as the same size?

-- 

#include <std_disclaimer.h>

Dan S.
From: tron@uophys.uoregon.edu (tron)
Newsgroups: comp.sys.mac.programmer
Subject: MacApp
Date: 8 Jan 93 21:51:39 GMT
Followup-To: comp.sys.mac.programmer
Organization: MSI- University of Oregon
NNTP-Posting-Host: teatime.uoregon.edu

I'm a beginner in Mac programming. Do I need MacApp? What is MacApp? Is it
similar to AppMaker? Where can I get MacApp and for how much?

thanks,
ron
Newsgroups: comp.sys.mac.programmer
From: garry@archsci.arch.su.edu.au (Garry Stevens)
Subject: Printing Regions
Followup-To: comp.sys.mac.programmer
Organization: Dept Architectural Science, Uni of Sydney
Date: Mon, 4 Jan 1993 08:10:13 GMT

I am having trouble with printing, regions and off-screen bitmaps (with
THINK Pascal 4.1). I construct my regions and then use the technique in
Tech Note #41 on drawing to an offscreen bitmap. This works fine for the
screen. The problem arises when I try to do the same for the Laserprinter.
I use exactly the same code. The regions are properly constructed, copied
and even printed just fine. But over the bottom third of the screen (and
overlapping the drawn area) is a random collection of junk, looking like
CopyBits copied too much and picked up some memory it should not have.

I also keep running into out of memory errors after I leave a (different)
printing process. THINK Pascal stops just before a TECalText call after the
printing is finished and it is updating the window. I do all the
(apparently) right things of closing the document, etc as per Tech Note
#161. Using the Observe window I call FreeMem and it shows 205K free.

Thanks for the assistance.

Garry Stevens
Dept of Architectural & Design Science
University of Sydney
Australia
Xref: sparky comp.sys.mac.programmer:20799 comp.os.ms-windows.programmer.tools:1893 comp.os.ms-windows.programmer.misc:4637
From: markf@zurich.ai.mit.edu (Mark Friedman)
Newsgroups: comp.sys.mac.programmer,comp.os.ms-windows.programmer.tools,comp.os.ms-windows.programmer.misc
Subject: Re: Stallman and friends
Date: 6 Jan 93 09:58:54
Organization: M.I.T. Artificial Intelligence Lab.
	<1993Jan05.231932.21087@eng.umd.edu>
Reply-To: markf@zurich.ai.mit.edu
NNTP-Posting-Host: montreux.ai.mit.edu
In-reply-to: russotto@eng.umd.edu's message of 5 Jan 93 23:19:32 GMT

In article <1993Jan05.231932.21087@eng.umd.edu> russotto@eng.umd.edu
(Matthew T. Russotto) writes:
** In article <1993Jan5.075021.970@shawn.uucp> root@shawn.uucp (Mark
** Jeghers -- UNIX/X/Motif Contractor) writes:
** >Please clarify.  What exactly do you believe are the real motives
** >of FSF and GNU?
** 
** They state them quite openly: they want software to be free, or at
** least they don't want people to have to pay for it with money.

My understanding is that according to the copyleft (and the GNU
manifesto) you may charge whatever you want for the software. However,
you must make the source freely available.

** They DON'T believe it should be free of attached strings, which say
** that anyone who uses their software must treat the product of their
** work in accordance with Stallman's wishes.

The copyleft (i.e. the "strings") are only there to counter existing
restrictive intellectual property laws. If those laws didn't exist
neither would the copyleft (and the need for it).

-Mark
--

Mark Friedman
42 Wyatt St.
Somerville, Ma. 02143

markf@zurich.ai.mit.edu
Newsgroups: comp.sys.mac.programmer
From: d88-jwa@byse.nada.kth.se (Jon Wtte)
Subject: Re: (Q) Need bit manipulation algorithm
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Mon, 11 Jan 1993 22:22:34 GMT

In <34440@goofy.apple.COM> chris_russo@gateway.qm.apple.com (Christopher Russo) writes:

>>>There is a neat trick for counting the number of bits in a word that
>>>a Microsoft geek showed me one time.  If there are k bits with 1's,
>>>it runs in O(k) time.

>I learned a cool way in an interview here at Apple.  For the number of 
>bits in a byte, all you'd need is a 256 byte look-up table where the 
>index designated by, say, 00001010 would be index $A into the table which 
>would contain the number 2 (that you put there.)  It's pretty fast.

Yes, but it runs in O(b) time, where b is the number of bits
(i.e. one table lookup for each byte in the word) It's not even
a neat trick; it's one of those friggin obvious things that
someone probably patented :-)

I still want to know the O(number-of-bits-set) algorithm.

Cheers,

						/ h+
-- 
 -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
   This signature is kept shorter than 4 lines in the interests of UseNet
   S/N ratio.
From: ksand@apple.com (Kent Sandvik )
Newsgroups: comp.sys.mac.programmer
Subject: Re: Wierd MPW Link error
Date: 7 Jan 93 06:47:54 GMT
Followup-To: comp.sys.mac.programmer
Distribution: comp
Organization: (Evil Eye Creature from Mars, Inc.)

In article <1993Jan5.215227.24036@uunet!tellab5!odgate>,
mike@uunet!tellab5!odgate (Mike J. Kelly) wrote:
> 
> While linking a large program divided into multiple libraries, I am
> getting the following error message:
> 
> Link: Error: Computed Ref ids not in same segment.  (Error 45) feselctl_is_feselctl_vact_armed (988)
> <Bad object file or compiler error.>
> 
> This program was compiling OK before I added the symbol named to one of the
> libraries it is reading.  Recompiling the file containing the symbol named
> and re-lib'ing the library does not solve the problem.
> 
> Does anyone know what this means and how to work around it?

Ref IDs are not used in many cases, one I know of is when you are
specifying the MPW C -bigseg flag.  I've seen such problems when
using MPW C++ with -bigseg, for instance. Try to use -model far
instead if you need >32k segments. The problem is that the compiler
makes two references, and the offset between them is the jump instruction
lenght. Well, if the references are in two different segments, you get
into trouble... So if you know what functions need these references,
move them to the same segment. However this is an empirical test
that may or may not end up in success, especially when you are dealing
with libraries. A quick hack would be to move the library segments into
main...

Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.		
Predictions: Soon moving to Newton DTS, bye bye.
Newsgroups: comp.sys.mac.programmer
From: jbush@magnus.acs.ohio-state.edu (J Eric Bush)
Subject: Re: Detecting mouse position in a window ?
Keywords: faq mouse in window regions etc help
Organization: The Ohio State University
Date: Tue, 12 Jan 1993 05:02:24 GMT

In article <rudolph.726810080@unixg.ubc.ca> rudolph@unixg.ubc.ca (Christopher E
 Rudolph) writes:

>I obviously need to be checking where the mouse is at any one time and act
>appropriately.  Does anyone have an example of how to do this gracefully.
>thanks, and sorry about it begin an FAQ

Just use the GetMouse(p:point) procedure.  If at first it gives you a global 
point, then all you have to do it say point:=GlobalToLocal(p).

Eric
-- 
------------------------------------------------------------------------------
J. Eric Bush
Internet: jbush@magnus.acs.ohio-state.edu
From: d88-jwa@dront.nada.kth.se (Jon Wtte)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Why the Piracy? Here's why...
Date: 11 Jan 93 18:38:33 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In <1is9edINN9s8@life.ai.mit.edu> mycroft@hal.gnu.ai.mit.edu (Charles Hannum) writes:

>> I hope that you produce something like a piece of software some day
>> and then get killed by pirates; we'll see how utopian you are then.

>I believe you missed something.  If it weren't for trade secrets,
>patents, and copyrights, writing software would be trivial; if I needed
>a fast algorithm for blitting on a Mac, for example, I'd just look it
>up.

>It is the very fact that we `protect' such information that causes it
>to become so valuable; everyone has to invest the time to reinvent it.

No; there's still much more to invent than to re-invent.

A fast MC68k blitter can be had, for instance, by calling
CopyBits, or reading any reference manual from Motorola.

Coming up with an algorithm is one thing, but writing software
is MUCH more than that; you have to IMPLEMENT the algorithm,
DEBUG the implementation, design a USER INTERFACE (this is one
of the hardest things) and define how FILE HANDLING works and
a lot of other things; none of this is covered by any kind of
patent, but it takes up 90% of the design team's time.

Not to mention manuals, training, testing, ...

As you see, your assertion that creating software would be
trivial if only patents and copyrights were banned is WHOLLY
INCORRECT.

Now, algorithm patents shouldn't last longer than 5 years,
but that's another story.

-- 
 -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
   This sig less than 3 lines: Improve the UseNet S/N ratio!
From: d88-jwa@dront.nada.kth.se (Jon Wtte)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Mem Mgr Max alloc size (Was: Re: Win 3.1 vs. Mac Toolbox Messaging (Question))
Date: 10 Jan 93 10:57:37 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In <hammett.726623377@sbsu1.aukuni.ac.nz> hammett@sbsu1.aukuni.ac.nz (Tim Hammett) writes:

>Actually, I think there is an 8 megabyte limit on memory manager
>pointer/handle allocations. I haven't tried it (don't have enough
>memory on this machine), but there's a line in Memory.h:

>    maxSize = 0x800000,     /*Max data block size is 8 megabytes*/

>I also remember something in Inside Mac about how enormous this 8M figure
>is compared with the amount of memory the Mac can take (this was back in
>the days on 128K/512K Macs). How times change. Unfortunately I haven't


With the advent of the 32bit Memory Manager, this constraint has
been lifted. (i.e. several years ago)

Cheers,

					/ h+
-- 
 -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --
  "You NEVER hide the menu bar. You might go about and change the color
  of it to the color of the BACKGROUND, but you never HIDE the menu bar."
                      -- Tog
Newsgroups: comp.sys.mac.programmer
From: bhanafee@picasso.ads.com (Brian Hanafee)
Subject: Re: Curves in QuickDraw GX
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
	960-7300
	<1993Jan1.183451.22522@nntp.hut.fi>
Date: Mon, 4 Jan 1993 22:44:31 GMT


In article <1993Jan1.183451.22522@nntp.hut.fi> jmunkki@vipunen.hut.fi (Juri Munkki) writes:
>I agree totally. In addition for QD GX, they used fixed point math. No
>current languages have built-in support for fixed point math, so a high
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*Almost* no current languages.  Ada does (see section 3.5.9 of the Ada
LRM).  Though I still wouldn't recommend using Ada to write QD GX,
it's a feature that of Ada that I'd really like to see in some other
languages.  Note that this is in addition to, not in place of, integer
and floating types.  When fixed point types are the right thing, it's
much easier than using integers and trying to keep track of the binary
point yourself.  Let the compiler do all the work!

>level implementation will not benefit fully from the integer speed of
>fixed point.

--
Brian Hanafee                         Advanced Decision Systems
bhanafee@ads.com                      1500 Plymouth Street
(415) 960-7300                        Mountain View, CA 94043-1230
Newsgroups: comp.sys.mac.programmer
From: russotto@eng.umd.edu (Matthew T. Russotto)
Subject: Re: (Q) Need bit manipulation algorithm
Date: Fri, 08 Jan 93 01:28:06 GMT
Organization: Project GLUE, University of Maryland, College Park

In article <20751@ucdavis.ucdavis.edu> lim@toadflax.cs.ucdavis.edu (Lloyd Lim) writes:
>
>There is a neat trick for counting the number of bits in a word that
>a Microsoft geek showed me one time.  If there are k bits with 1's,
>it runs in O(k) time.

They probably use it job interviews....

ones = 0;
while (k) {
	k=k&(k-1);
	ones++;
}



-- 
Matthew T. Russotto	russotto@eng.umd.edu	russotto@wam.umd.edu
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)
Newsgroups: comp.sys.mac.programmer
From: mark@bilpin.co.uk (Mark Allerton)
Newsgroups: comp.sys.mac.programmer
Subject: Re: How do I make my windows handle a multiple-monitor system?
Date: 6 Jan 93 13:27:56 GMT
Reply-To: mark@bilpin.co.uk (Mark Allerton)
Organization: SRL Data

Brian Kendig writes:
------
The windows in my program work just fine with a single-monitor system,
but they have problems when the user tries to drag or zoom them on a
Macintosh with more than one monitor connected to it.

To drag the window, I just set up a drag rect with

	dragRect = screenBits.bounds;
	dragRect.left += DRAG_THRESHOLD;
	dragRect.right -= DRAG_THRESHOLD;
	dragRect.bottom -= DRAG_THRESHOLD;

then do a DragWindow(whichWindow, theEvent.where, &dragRect). 
etc.
--------

How big is DRAG_THRESHOLD?

The thing is that (you may already know this) screenBits.bounds
defines the bounds of the *main screen*, rather than the rectangle
that encloses all of the screens (which you can get by looking at
the rgnBBox field of the region returned by GetGrayRgn.)

Fortunately for people who wrote thier code before multi-screen
Macs arrived, and to make life easier for everybody, DragWindow
checks to see how close the drag rectangle is to screenBits.bounds,
and if it's close enough, allows the user to drag across all of the
screens. I can't remember offhand what "close" is defined as, but
I think it's within 6 pixels at left, right and bottom (top being
different because it's normally adjusted to allow for the menu 
bar.)

So if DRAG_THRESHOLD is too big, you'll end up stuck on the main 
screen...


Mark Allerton - mark@bilpin.co.uk
SRL Data, but I speak for myself.
From: mycroft@hal.gnu.ai.mit.edu (Charles Hannum)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Why the Piracy? Here's why...
Date: 11 Jan 93 17:06:21 GMT
Organization: /etc/organization
NNTP-Posting-Host: hal.gnu.ai.mit.edu


In article <1993Jan10.114839.10045@ac.dal.ca> seanmcd@ac.dal.ca writes:
>
> I hope that you produce something like a piece of software some day
> and then get killed by pirates; we'll see how utopian you are then.

I believe you missed something.  If it weren't for trade secrets,
patents, and copyrights, writing software would be trivial; if I needed
a fast algorithm for blitting on a Mac, for example, I'd just look it
up.

It is the very fact that we `protect' such information that causes it
to become so valuable; everyone has to invest the time to reinvent it.

-- 
 \  /   Charles Hannum, mycroft@ai.mit.edu
 /\ \   PGP public key available on request.  MIME, AMS, NextMail accepted.
Scheme  White heterosexual atheist male (WHAM) pride!
Newsgroups: comp.sys.mac.programmer
Subject: Summary: Disassembler utilities
From: seth@physc1.byu.edu
Date: 7 Jan 93 23:56:54 -0700
Distribution: world
Organization: Brigham Young University

Many thanks to the several people who sent me suggestions about a disassembler. 
To summarize, there is a code viewer feature that can be added to ResEdit that 
allows one to look at the code in assembly rather than straight hex. It also 
has other functionality that I am still trying to sort through. VERY nice, BUT
I haven't figured out a way to just capture as straight text the disassembled 
stuff and paste it in to an inline assembly section in THINK C, sans the info
regarding the actual offsets, of course. I haven't been able to find ANY way to
get the assembly out as text; if there is a way, someone please inform me.This 
code viewer for Resedit can be found at ftp.apple.com in (I believe)
dts/mac/tools/resedit. 
There is also a Shareware utility written called RSC_VIEWER, which is 
available at sumex-aim.stanford.edu in info-mac/demo. It allows one to edit,
disassemble, assemble, etc. code resources, and edit any resource, as far as I
know. It seems to be very functional, even if the menus are rather unclear, and
I was confused at just how to procede several times. This has a shareware fee
of $35, which would probably be well worth it to someone who likes to edit the
code resources. I, as a student, can't afford a $35 shareware fee, as low as it
may seem for a work of this magnitude; maybe this spring when I earn more 
money...
Mainly I am looking for JUST a disassembler that will allow one to capture the
disassembled code as text and copy it into THINK C, that's why I can't afford
RSC_VIEWER; the fee covers much more functionality than I need.
There is also a disassembler called MacNosy that comes with some commercial
debugging package. The person who told me about this didn't specify which
package; I suspect TMON, but I don't know for sure.

THanks again for all the comments and emails, and if someone knows of a (free)
way to disassemble and capture as text, I would be glad to hear about it ;).

Seth Leigh
BYU PHysics Dept.
From: rduta@nyx.cs.du.edu (Radu)
Subject: Re: Sozobon (or other free C's): would this strategy work?
Organization: Nyx, Public Access Unix @ U. of Denver Math/CS dept.
Distribution: comp
Date: Thu, 7 Jan 93 17:58:34 GMT

quoting from neeri@iis.ethz.ch (Matthias Neeracher)
"
I don't think that's the reason. Lots of other hacker's tools have been ported,
but gcc and emacs are just rather big programs and the Mac is not particularly
UNIX compatible (gcc and emacs *are* available under A/UX, which sort of proves
my point). Another reason against porting gcc is that there are already at
least two powerful, well-integrated compilers around. I doubt that you could
get gcc to compile even as fast as MPW C, let alone Think C, especially if you
consider that gcc needs a separate assembly step. If you add the necessity of
writing a decent user interface for a standalone compiler, I doubt that people
will be willing to spend a lot of effort in writing the 3rd fastest and 3rdmost
compatible C compiler for the Mac (If anybody *is* willing, though, I applaud
his dedicationand he might get famous).
 
> But I think a lot of people would benefit from a port,
> given the large numbers of Mac users.
 
My parents use Macs, too, but I doubt they would benefit from a port.
Seriously, though, I think the target audience is not that big. gcc is too big
for amateur programmers, too slow for many non-amateurs, and some programmers
wouldn't like to use a standalone compiler (I want my MPW :-).
"
end quote!!!



I take that whole post as a direct insult!  Sure your parents might use a mac,
but so do I, and i'm not by any means related to you.  Just because you have
the money to go ahead and buy MPW or Think C, doesn't mean that everyone can.
I for one can't even come close to spitting out the $150 for Think C.  I'm 
currently a student in colege so that could explain the lack of funds.  On
the other hand I'm using a Mac + which i bought for less that 200.  So
before i spend more money on a compiler than I spend for my comuter i'll
much rather buy another computer.  

I hapen to agree with FSF drive against apple, I'm all for it, and i think they
have a good reason for it as well.  Apple has had the bad habbit of
ripping people off since the bigining of time.  

recently i was debating buying a  mac CI for 2000, noting how much prices
came down, but then I saw a 486 66 for only 1000.  Now lets face it, a 486
66 will cream a 68030 25.  Put linux on it, and your set, not to mention
that i'll have all the code that has ever been written for unix.  

I strongly feel that someone should write a port for GCC, something that
is independant of MPW, or any other comertial product.  I can't make it happen
since I don't know enough, but i hope someone that knows enough can and will
do it.     Make it happen!


--
********************************************************************************
I only kill to know I'm alive!
Newsgroups: comp.sys.mac.programmer
From: cca@sscux1.ssc.gov (Charles Allen)
Subject: SmalltalkAgents (QKS) at MacWorld?
Organization: UTexas-Austin Physics
Date: Tue, 12 Jan 1993 21:44:40 GMT

The inside back cover of the 1993 January MacTech has an ad from
Quasar Knowledge Systems for SmalltalkAgents.  I called for info and
received a glossy brochure.  It's basically a Smalltalk development
system tailored to the Mac.  In general it looks quite intriguing,
although the $200 runtime killed any hopes I had of using it for any
projects.  I certainly won't buy a development environment that won't
let me give away applications I develop.  Nevertheless, I'm interested
in any data from MacWorld, where QKS supposedly had a demo in Apple's
Tools Exhibit, whatever that was.  Surely *somebody* out there saw it
in action.

Charles Allen        UTexas-Austin Physics        allen@uthep2.ph.utexas.edu
Newsgroups: comp.sys.mac.programmer