whipple@sun.udel.edu (Peter Adams Whipple) (07/02/90)
Windows may not have a resource "fork" as Mac files do, but it does use resources. And The Whitewater Group has a resource editor (Whitewater Resource Toolkit for Windows) that does much of what ResEdit does. | Peter A. Whipple | whipple@sun.udel.edu | ACIT / IT | "Methane? You're inthane!" | University of Delaware | -- Good Neighbors
strobl@gmdzi.UUCP (Wolfgang Strobl) (07/02/90)
pfr654@csc.anu.oz writes: >But, one thing that strikes me about the Mac, from a software point of >view, is the nice thing known as the resource fork and ResEdit etc. >Apparently (and I have no facts on this, so someone should correct me) win >3 requires lots and lots of disks (I heard 50MB worth) to do the sort of >stuff that ResEdit/Font/DA mover do? >How easy or otherwise can it be to translate a program without the Resource >Fork? >Do any other computer systems use such a method of programming?-- From the Microsoft Windows Software Development Kit, Programmer's Learning Guide, Version 2 (sorry, I haven't version 3, yet), quoted without permission: 2.5 Building a Windows Application You build a Windows application by following these steps: 1. Write the WinMain and window functions and place them in C-language or assembly-language source files. 2. Write the menu, dialog box, and other resource descriptions and place them in a resource script file. 3. Use Icon Editor to create the cursors, icons, and bitmaps. 4. Use Dialog Editor to create dialog boxes. 5. Write the module definitions and place them in the module definition file. 6. Compile and link all C-language sources. 7. Compile the resource script file and add it to the executable file. [End of quote] It is possible to repeat step 2, 3, 4 and 7 without repeating the source compilation step (6). The resource compiler used in step 7 compiles all resources (menues, dialog boxes, icons, cursors, bitmaps and private resources) into one binary resource file and adds this to the load module. Translation of a program is normally done without touching the program source code, using different sets of resources and resource scripts. Of course, this feature is available to developers only. But there exists a commercial resource editor, which is able to extract and edit resources contained in the executable file. Is this really that much different from the way resources are handled on the Macintosh? Wolfgang Strobl #include <std.disclaimer.h>
wilkins@jarthur.Claremont.EDU (Mark Wilkins) (07/02/90)
In article <2964@gmdzi.UUCP> strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >Is this really that much different from the way resources are handled on the >Macintosh? It depends entirely on whether there are system calls implemented which allow the program to modify the resource file on the fly, so to speak. I know nothing of Windows, but your description does not address whether such features exist. If there are such calls, then yes, they are much alike. If not, then I'd say the Mac implementation is much more useful. -- Mark Wilkins
philip@pescadero.Stanford.EDU (Philip Machanick) (07/02/90)
In article <2964@gmdzi.UUCP>, strobl@gmdzi.UUCP (Wolfgang Strobl) writes: > Is this really that much different from the way resources are handled on the > Macintosh? Probably not, but the Mac also allows you to add resources to things which weren't designed to have them, like documents. In this way, for example, MPW can store information about the state a document's window was in, without messing the file up for a program which only knows about plain text. It's hard to see how this could be achieved without making resources a concept explicitly known to the underlying file system. Philip Machanick philip@pescadero.stanford.edu
pfr654@csc.anu.oz (07/02/90)
I've read lots of stuff about windows 3.0 and have heard quite a lot from a Mac freind who has to use IBM machines at work (he is busy installing win 3 on lots of IBM type machines). But, one thing that strikes me about the Mac, from a software point of view, is the nice thing known as the resource fork and ResEdit etc. Apparently (and I have no facts on this, so someone should correct me) win 3 requires lots and lots of disks (I heard 50MB worth) to do the sort of stuff that ResEdit/Font/DA mover do? How easy or otherwise can it be to translate a program without the Resource Fork? Do any other computer systems use such a method of programming?-- *====*===*===*===*===*===*===*===*===*===*===*===*===*===*===*===* Phil Ryan ANU Department of Physics and Theoretical Physics Canberra, Australia pfr654@csc.anu.oz.au phone:(61 6) 249 4678 fax:(61 6) 249 0741
strobl@gmdzi.UUCP (Wolfgang Strobl) (07/03/90)
wilkins@jarthur.Claremont.EDU (Mark Wilkins) writes: >In article <2964@gmdzi.UUCP> strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >>Is this really that much different from the way resources are handled on the >>Macintosh? > It depends entirely on whether there are system calls implemented which >allow the program to modify the resource file on the fly, so to speak. > I know nothing of Windows, but your description does not address whether >such features exist. If there are such calls, then yes, they are much >alike. If not, then I'd say the Mac implementation is much more useful. >-- Mark Wilkins I know nearly nothing of the Mac's API, but I am willing to learn. Why would one want to modify the resource file on the fly? I can think about a few reasons myself, and there is surely a lack of system call support in the resource area of MS Windows. But there are other features (dynamic link libraries, for example) which could compensate for that. But this depends on what the system calls you refer to are used for. Wolfgang Strobl
daveo@Apple.COM (David M. O'Rourke) (07/03/90)
strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >I know nearly nothing of the Mac's API, but I am willing to learn. >Why would one want to modify the resource file on the fly? I can think >about a few reasons myself, and there is surely a lack of system call support >in the resource area of MS Windows. But there are other features (dynamic link >libraries, for example) which could compensate for that. But this >depends on what the system calls you refer to are used for. Storing of preference's and such type of data is one reason. Another is to allow programmer's to store "ANY" kind of data that is a unit of information. The Mac's resource fork allows you to keep status information about other resources, or even the data in the data fork. In addition it is a miny data base manager, although it's slow, it is possible to read resources in modify them and then write them out with out worrying about the "placement" of the information within the file, and without disrupting the "stream" data in the data fork. This allows several program's to store status information about the same data file, without stepping on one another. If you'd like more detail I'd be happy to discuss the advantages of the resource file concept, and point out some of the problems with the Mac's current implemenation. The concept is sound and more extensive that Window's current view, but the Mac's implementation is somewhat limited due to the early requirments of the 128K mac...but that's another story. -- daveo@apple.com David M. O'Rourke _______________________________________________________________________________ I do not speak for Apple in *ANY* official capacity.
strobl@gmdzi.UUCP (Wolfgang Strobl) (07/03/90)
philip@pescadero.Stanford.EDU (Philip Machanick) writes: >In article <2964@gmdzi.UUCP>, strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >> Is this really that much different from the way resources are handled on the >> Macintosh? >Probably not, but the Mac also allows you to add resources to things which >weren't designed to have them, like documents. In this way, for example, >MPW can store information about the state a document's window was in, >without messing the file up for a program which only knows about plain text. >It's hard to see how this could be achieved without making resources a >concept explicitly known to the underlying file system. Ok, this is a useful feature which is missing in MS Windows, version 2 (and 3, as far as I can tell). This is why some people would like to switch to OS/2 with presentation manager, which HAS this capability. It is simulated with a large hidden file if the old FAT file system is used, and is built into the new High Performance File System. Wolfgang Strobl #include <std.disclaimer.h>
strobl@gmdzi.UUCP (Wolfgang Strobl) (07/03/90)
daveo@Apple.COM (David M. O'Rourke) writes: >strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >>I know nearly nothing of the Mac's API, but I am willing to learn. > ... > If you'd like more detail I'd be happy to discuss the advantages of the >resource file concept, and point out some of the problems with the Mac's >current implemenation. The concept is sound and more extensive that >Window's current view, but the Mac's implementation is somewhat limited due >to the early requirments of the 128K mac...but that's another story. Thank you for your this description. Yes, I would like more detail and learn about the differences between the two environments, both from a users and a programmers view. Do you think that there is enough interest here in this group to continue this discussion in public? Wolfgang Strobl #include <std.disclaimer.h>
mike@dayton.UUCP (Mike Baillargeon) (07/03/90)
In article <2966@gmdzi.UUCP> strobl@gmdzi.UUCP (Wolfgang Strobl) writes: > >Why would one want to modify the resource file on the fly? I can think > >Wolfgang Strobl The most obvious reason is for different language types. The same program will work in english, french, german even korean without significant changes if all the text and window definitions are in separate resources. Other reasons are for user options, instead of keeping a preference file, some programs update their own resources for different menu options or command keys. Several major packages also use a preferences file also. --Mike -- +--------------------------------------------------------------------------+ | Mike Baillargeon | As expected all opinions stated | | mike@dayton.DHDSC.MN.ORG | are my own and mine alone. | |----------------------------------------|---------------------------------| | If I am elected, 2 Macintosh's in every office. | +--------------------------------------------------------------------------+
marmoset@ub.cc.umich.edu (Dave Walker) (07/04/90)
Followup To: comp.sys.mac.programmer <Stuff about programming and the resource fork deleted...> In article <2970@gmdzi.UUCP> strobl@gmdzi.UUCP (Wolfgang Strobl) writes: > Thank you for your this description. Yes, I would like more detail and > learn about the differences between the two environments, both from a > users and a programmers view. Do you think that there is enough interest > here in this group to continue this discussion in public? Probably, but comp.sys.mac.programmer would probably be a better forum for it than comp.sys.mac.misc. +------------------------------------------------------------------------+ | Dave Walker, Marmoset Pty. Ltd. | | marmoset@ub.cc.umich.edu "I don't read, I just guess" | | marmoset@mondo.engin.umich.edu -Happy Mondays, "Wrote For Luck" | +------------------------------------------------------------------------+
kassarji@boulder.Colorado.EDU (KASSARJIAN STEVEN J) (07/04/90)
In article <2966@gmdzi.UUCP> strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >Why would one want to modify the resource file on the fly? I can think One reason is the ability for the user to easily change the functionality of the program. For instance, a number of the readily available text editors for programmers have what I consider inconvenient command key equivalents. ResEdit allows users to alter these. One of Apple's major reasons for the resource was to make modifying a program for use in different countries much easier. Instead of changing all the text in a program from English to French, and then recompiling and relinking, the translater merely has to modify the text (e.g., menu titles) in the resource. Apologies to those to whom this is old hat. Steve.
siegman@sierra.STANFORD.EDU (siegman) (07/04/90)
Please DO continue the discussion of the Mac's resource fork, its
strobl@gmdzi.UUCP (Wolfgang Strobl) (07/04/90)
mike@dayton.UUCP (Mike Baillargeon) writes: >In article <2966@gmdzi.UUCP> strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >> >>Why would one want to modify the resource file on the fly? I can think >> >>Wolfgang Strobl >The most obvious reason is for different language types. The same program >will work in english, french, german even korean without significant changes >if all the text and window definitions are in separate resources. As far as PROGRAMS are concerned, there seems to be not much difference in resource handling between MS Windows and the Macintosh OS, because in both environments string constants, menue descriptions, dialog boxes, etc. (i.e. most of the visible stuff) is contained in separate resources. My above question about the uses for modifying resource files on the fly has since been answered, mostly. But your above statement isn't an answer. Normally there is no need to switch a program between languages ON THE FLY. >Other reasons are for user options, instead of keeping a preference file, >some programs update their own resources for different menu options or >command keys. Several major packages also use a preferences file also. The advantage of having configuration information in a program's resources seems to be that it gets copied with the program, automatically, and one does not have to remember the location of the preference file. This is nice, indeed. MS Windows has a mechanism to store keyword=value pairs for applications and has access functions to update them, which serves a similar purpose. The table is stored in one place (file) in plain text. Easy to edit with a simple text editor, but inefficient, and not very usable for large amounts of data. Wolfgang Strobl #include <std.disclaimer.h>
strobl@gmdzi.UUCP (Wolfgang Strobl) (07/05/90)
kassarji@boulder.Colorado.EDU (KASSARJIAN STEVEN J) writes: >In article <2966@gmdzi.UUCP> strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >>Why would one want to modify the resource file on the fly? I can think >One reason is the ability for the user to easily change the functionality of >the program. For instance, a number of the readily available text editors >for programmers have what I consider inconvenient command key equivalents. >ResEdit allows users to alter these. >One of Apple's major reasons for the resource was to make modifying a program >for use in different countries much easier. Instead of changing all the text >in a program from English to French, and then recompiling and relinking, the >translater merely has to modify the text (e.g., menu titles) in the resource. >Apologies to those to whom this is old hat. This includes Windows Programmers, too. There seems to be NO DIFFERENCE between MS Windows and the Macintosh OS, here. Both separate programs into a user interface part (icons, bitmaps, menues, keyboard accelerators, string constants, dialog boxes, ...) and the algorithmic part. Both do not need a recompilation for changing the user interface. Wolfgang Strobl >Steve.
daveo@Apple.COM (David M. O'Rourke) (07/05/90)
strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >This includes Windows Programmers, too. There seems to be NO DIFFERENCE >between MS Windows and the Macintosh OS, here. Both separate >programs into a user interface part (icons, bitmaps, menues, keyboard >accelerators, string constants, dialog boxes, ...) and the algorithmic >part. Both do not need a recompilation for changing the user interface. Real Questions: Can you change the resources "in-place" in the file, change their sizes, attributes and possibly add resources, or delete them, with out re-linking?? As I understand Window's resource concept it's a nice way to separate data from the code, but it's not a resource management system that allows you to change, modify, delete, and resize existing resources "in-place" in the file without re-building the file through some linking process. Can programs add, delete, change, resize resources at run time to any file?? And if they can is there OS support for this operation, or do you have to implement the routines yourself?? Can you "search" for a particular type of resource, providing a simple form of dynamic linking Now on to Mac related topics of resources: In addition when you recall a resource on the Macintosh it "searches" all open resource files to attempt to find the resource. This allows Apple to put standard dialogs and such in the system file, which is always open, and they can be used by programs, and OS routines. But if a programmer places a resource of the idential type/id in his application it will override the system based resource and use the one it finds in the Application, and if you do it right you can even subsitute your own data {dialog, icon, bitmap, etc.} and still use the OS routine that uses it. There by reusing the OS code, but changing the interface by the simple addition of a resource to your Application. From talking to a friend of mine who's a competent programmer in both enviroments he seems to feel that MS Windows resource management is a step forward for the separation of Data and Code, but it's not as dynamic and the Mac's resource manager and lacks some of it's functionality. But I'm willing to listen to arguments about how MS Windows is just as functional... -- daveo@apple.com David M. O'Rourke _______________________________________________________________________________ I do not speak for Apple in *ANY* official capacity.
strobl@gmdzi.UUCP (Wolfgang Strobl) (07/05/90)
daveo@Apple.COM (David M. O'Rourke) writes: >strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >>This includes Windows Programmers, too. There seems to be NO DIFFERENCE >>between MS Windows and the Macintosh OS, here. Both separate >>programs into a user interface part (icons, bitmaps, menues, keyboard >>accelerators, string constants, dialog boxes, ...) and the algorithmic >>part. Both do not need a recompilation for changing the user interface. > Real Questions: > Can you change the resources "in-place" in the file, change their sizes, >attributes and possibly add resources, or delete them, with out re-linking?? Yes and no. The resource compiler has in fact two different functions. Function one is the compilation of a resources script into a binary resource. Function two is adding such a binary resource to a completely linked program. This second function can be applied more so once, so I can do it. But I would not call this "changing resources in-place". There is a commercial resource editor which claims to be able to extract and edit resources. So far I have used the Microsoft Windows SDK (System Development Kit) of version 2 and documented interfaces only, so I can't tell you anything about it. There is no documented interface for changing resources in Windows 2 as far as I know, and all this applies to programs only, anyway. > As I understand Window's resource concept it's a nice way to separate >data from the code, but it's not a resource management system that allows you >to change, modify, delete, and resize existing resources "in-place" in the >file without re-building the file through some linking process. Yes, but see above. And as far as programs a concerned, this is more the problem of some missing documentation and/or tools. And I normally dont want to change my program on the fly. > Can programs add, delete, change, resize resources at run time to any file?? >And if they can is there OS support for this operation, or do you have to >implement the routines yourself?? Don't make the fault of just looking for exact duplicates of Macintosh functionality in MS Windows. Windows is built on top of an simple operating system which has a file system which knows nothing about resources. Programs got a new load module format with Windows, so a place for resources could be added there. But this is for constant data, only. For variable information there is a documented interface to manipulate named tables of keyword=value pairs. It is heavily used to store all kinds of configuration information. > Can you "search" for a particular type of resource, providing a simple form >of dynamic linking I can place resources (common or custom ones) into a dynamic link library, get a handle for it with LoadLibrary, use FindResource to search for a specific resource by name or number and type, get a handle on that with LoadResource, and finally load it by using LockResource. > Now on to Mac related topics of resources: > In addition when you recall a resource on the Macintosh it "searches" all >open resource files to attempt to find the resource. This allows Apple to >put standard dialogs and such in the system file, which is always open, and >they can be used by programs, and OS routines. But if a programmer places >a resource of the idential type/id in his application it will override the >system based resource and use the one it finds in the Application, and if you >do it right you can even subsitute your own data {dialog, icon, bitmap, etc.} >and still use the OS routine that uses it. There by reusing the OS code, but >changing the interface by the simple addition of a resource to your Application. This sounds indeed nice. A few questions: what is the search order in the above resource search, i.e. what if there is more than one program running and both have open resources files? In order to have an OS routine use my own resource, I have to know some details about the internals of this routine. Is all this officially documented? > From talking to a friend of mine who's a competent programmer in both >enviroments he seems to feel that MS Windows resource management is a step >forward for the separation of Data and Code, but it's not as dynamic and the >Mac's resource manager and lacks some of it's functionality. But I'm willing >to listen to arguments about how MS Windows is just as functional... I would never claim that MS Windows is as functional as the Mac in the resource area. It cannot, because it has to live with an old file system. What I claim is that a) there are areas where MS Windows is more functional and b) there has been some misinformation here in this group about Windows, recently. I do not have strong opinions about what system is better, I like both, and I think that some kind of misinformation is bad for both systems, in the long run. Wolfgang Strobl #include <std.disclaimer.h>
daveo@Apple.COM (David M. O'Rourke) (07/06/90)
strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >This sounds indeed nice. A few questions: what is the search order in the >above resource search, i.e. what if there is more than one program running >and both have open resources files? In order to have an OS routine use my >own resource, I have to know some details about the internals of this >routine. Is all this officially documented? The search order is the most recently opened resource fork first, then the next one, next one, and finally the System File itself. As far as having more than one Application with an open resource fork Mulit-Finder keeps the resource search so that it appears "correct" to the currently running Application and only searches the System Wide resource forks, and any files the Application opened. Yes this is all officially documented as the Resource Manager was designed that way on purpose. ps. There has been an optimization that you can "force" the resource manager to only serach the most immediate resource file for the requested resource. A typical resource search path would look like the following.... System File <---- Application <--- <addition files opened by App.> Last File Next-to-last search order reverse of open order. Thankyou for the information, nice to see a measured response with some good content rather than the random flames. Any additional questions will be gladly answered. -- daveo@apple.com David M. O'Rourke _______________________________________________________________________________ I do not speak for Apple in *ANY* official capacity.
strobl@gmdzi.UUCP (Wolfgang Strobl) (07/06/90)
daveo@Apple.COM (David M. O'Rourke) writes: > Any additional questions will be gladly answered. Thank you. At this time I only have two more questions: a) How does the Multifinder work? More specific, how is the memory allocation organized? Is there some kind of memory partition, or is it dynamic? b) Please recommend a Macintosh book similar to what Charles Petzold's "Programming Windows" is for MS Windows. (-; I do not want to dig through reference manuals. Instead I would like to read a well written, structured introduction into Macintosh architecture and programming. I prefer code examples in C or C++. Wolfgang Strobl
daveo@Apple.COM (David M. O'Rourke) (07/07/90)
strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >a) How does the Multifinder work? More specific, how is the memory > allocation organized? Is there some kind of memory partition, or > is it dynamic? NOTE: I don't work in the OS group so I'm not privy to the real deep internals of Multi-finder and I am attacking this question from a rather high-level. I would welcome any details or corrections that might be overlooked in my answer. Just because I work for Apple doesn't mean I have the time to "know" everything, although I'll keep trying. :-) :-) I don't believe MF's memory allocation is as robust as MS windows due to some of the limitation of maintaining compatibility with early Mac's :-( But the Mac's memory management scheme allows for multiple heap zone's in a single contiguous memory map. Multi-finder creates a single contiguous heap for each process and all the programs memory allocations generally come out of that heap. When a program quits all of the heap space is returned to MF's free space and it might/might-not be allocated again depending on demand. Short answer: Yes there is a memory partition and it is not dynamic. >b) Please recommend a Macintosh book similar to what Charles Petzold's > "Programming Windows" is for MS Windows. (-; I do not want to dig > through reference manuals. Instead I would like to read a well > written, structured introduction into Macintosh architecture and > programming. I prefer code examples in C or C++. I've yet to see an excellent book for programming the Mac. But Apple's "Programmer's Introduction to Macintosh" does a good job, and Macintosh Revealed is also quite nice. Any other suggestions from netland??? -- daveo@apple.com David M. O'Rourke _______________________________________________________________________________ I do not speak for Apple in *ANY* official capacity.
cluther@supernet.UUCP (Clay Luther) (07/08/90)
strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >This includes Windows Programmers, too. There seems to be NO DIFFERENCE >between MS Windows and the Macintosh OS, here. Both separate >programs into a user interface part (icons, bitmaps, menues, keyboard >accelerators, string constants, dialog boxes, ...) and the algorithmic >part. Both do not need a recompilation for changing the user interface. >Wolfgang Strobl Hmm, well, actually, code is stored in the resource fork. The data fork is used to store just that, data. Actually, the way I think of it is: the resource fork is a collection of definite objects that can be read, written, deleted and modifed on demand without having to know the structure of the file or actually anything about the object itself (Since a simple call to GetNextResource() returns an anonymous handle). the data fork, on the other hand, is nothing more than a stream of bytes, and requires intimate knowledge about its structure. However, a note: although when we talk of a file having a data and resource fork, this is a misonomer: macintosh files are virtual structures, actually composed of two files (the forks) which are irrevocably linked. This was a major problem with early (still?) inceptions of the multi-finder. MF has a open file limit of around 20 or so. Each file or application you open can cause up to 2 of the file pointers to be allocate - one for the file's or application's resource fork, another for the data fork. If you were in, say a word processor and a paint program, and editing 3 files each, well that could be 16 of your 20 pointers, leaving you only ernough room to open another app and maybe one to three files. And even though you might have 8 megs out there and no where near your capacity, MF would not let you open any more files. -- Clay Luther ..uunet!iex!supernet!cluther Usenet Administrator supernet!cluther%iex.uucp@dept.csci.unt.edu Harris Adacom Corp, Dallas, Tx cluther@supernet.UUCP iex!supernet!cluther@uunet.UU.NET
jamesth@microsoft.UUCP (James THIELE) (07/09/90)
In article <3052@gmdzi.UUCP> strobl@gmdzi.UUCP (Wolfgang Strobl) writes: | |b) Please recommend a Macintosh book similar to what Charles Petzold's | "Programming Windows" is for MS Windows. (-; I do not want to dig | through reference manuals. Instead I would like to read a well | written, structured introduction into Macintosh architecture and | programming. I prefer code examples in C or C++. Do you want a book on Mac programming with as many mistakes, unexplained assumptions, and outdated examples as Petzold? Could be hard to find. :-) | |Wolfgang Strobl James Thiele -- microsoft!jamesth
strobl@gmdzi.UUCP (Wolfgang Strobl) (07/10/90)
cluther@supernet.UUCP (Clay Luther) writes: >strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >>This includes Windows Programmers, too. There seems to be NO DIFFERENCE >>between MS Windows and the Macintosh OS, here. Both separate >>programs into a user interface part (icons, bitmaps, menues, keyboard >>accelerators, string constants, dialog boxes, ...) and the algorithmic >>part. Both do not need a recompilation for changing the user interface. >>Wolfgang Strobl >Hmm, well, actually, code is stored in the resource fork. The data fork is used >to store just that, data. Actually, the way I think of it is: (explanation of resource handling on Macs deleted) This is getting out of context. My above remark was a reply to a misleading statement about Windows, which compared the ability of the Mac OS to handle user interface changes like translation into foreign languages without recompilation with the pretended inability of MS Windows to do that. Besides, code needs recompilation, right? Anyway, thanks for your description of the Macs resource model. I is an definite advantage to have such structures built right into the file system, and MS Windows is surely lacking such support from MSDOS's file system. Some support has been put into the new load module format Windows uses, but the API access is static and there is no similar thing for data files, so far. But that's nothing which couldn't be changed by putting a new file system below Windows. Wolfgang Strobl #include <std.disclaimer.h>
strobl@gmdzi.UUCP (Wolfgang Strobl) (07/10/90)
jamesth@microsoft.UUCP (James THIELE) writes: >In article <3052@gmdzi.UUCP> strobl@gmdzi.UUCP (Wolfgang Strobl) writes: >| >|b) Please recommend a Macintosh book similar to what Charles Petzold's >| "Programming Windows" is for MS Windows. (-; I do not want to dig >| through reference manuals. Instead I would like to read a well >| written, structured introduction into Macintosh architecture and >| programming. I prefer code examples in C or C++. >Do you want a book on Mac programming with as many mistakes, >unexplained assumptions, and outdated examples as Petzold? >Could be hard to find. :-) Not so. The Microsoft Windows System Development Toolkit I got from Microsoft Germany was incomplete and outdated right out of the box. I have learned Windows programming the hard way, using the SDK only, because at the time I started looking into Windows nothing else was available here in Germany. I got Petzolds book later and have read it with much pleasure. If you want to see a bunch of unexplained assumptions, just take a look into page 196 ff. of "The Macintosh Programmer's Introduction to Windows" of the Windows SDK and appreciate how local heap handles are cast into pointers and back in the "Shapes for Windows" sample windows code. Just the right thing to confuse a newcomer completely. >James Thiele -- microsoft!jamesth Wolfgang Strobl #include <std.disclaimer.hpp>