Professional Web Applications Themes

INI files? Porting from XP to OS X - Mac Programming

Hi! I'm porting a whole set of my WinXP software to Mac OS X. It consists of device drivers, an MDI application and some SDI applications. All of these things must "reach" an INI file (on XP) to write/read from. One application puts stuff into the INI file, then tells the device driver to load the INI contents, when other application is currently working with the driver, etc... I can't put this file inside one .app, since a device driver (.kext) can't be the same app as my other applications. I guess I'll have a kext and at least 2-3 ...

  1. #1

    Default INI files? Porting from XP to OS X

    Hi!

    I'm porting a whole set of my WinXP software to Mac OS X.
    It consists of device drivers, an MDI application and some SDI applications.
    All of these things must "reach" an INI file (on XP) to write/read from.
    One application puts stuff into the INI file, then tells the device driver
    to load
    the INI contents, when other application is currently working with the
    driver, etc...

    I can't put this file inside one .app, since a device driver (.kext) can't
    be the
    same app as my other applications. I guess I'll have a kext and at least 2-3
    different .app-s which all must deal with the same "INI" file.

    What is the equivalent technique on Mac OS X to Windows INI files and
    where should I store such a commonly used file? (on Windows its best place
    is in the Windows root folder)

    Thank you for any comments, corrections, ideas!

    Regards,
    Greg


    Greg Guest

  2. #2

    Default Re: INI files? Porting from XP to OS X

    In article <bov8fm$1u2$matavnet.hu>, "Greg X" <com> wrote:
     

    You should keep in mind that there is no such thing as MDI vs. SDI on the Mac.
     

    The reason you can't put it inside the app is that you can't assume you have the
    privileges to modify yourself.
     

    You need to decide whether this file contains:

    a. preferences
    b. application support resources

    A preferences file is something that I would feel sad about losing, because it
    contains some configuration that I went through a lot of work to create. A
    support file is something that belongs to the application and if I throw it out,
    the app will recreate it, or I will have to reinstall the app.

    You also need to decide whether this is

    a. a per-user file
    b. system-wide file

    It's a per-user file if it makes sense for different users to have different
    versions of this file. (Don't forget that multiple users can be logged in at
    once.)

    Finally, you need to decide whether you want to use

    a. a proprietary file format
    b. a Mac OS X API

    to store the data. If you already have your own file format and a pr for it,
    then it's probabyl easier to use the same format on Mac OS X. If you are using a
    windows API to maintain the file, then you are probably better off using a
    similar Mac OS X API to maintain the file.

    If you decide to maintain the file yourself:

    User preferences live in the location returned by FSFindFolder(kUserDomain,
    kPreferencesFolderType).
    User application support items live in the location returned by
    FSFindFolder(kUserDomain, kApplicationSupportFolderType).
    Global preferences live in the location returned by FSFindFolder(kLocalDomain,
    kPreferencesFolderType).
    Global application support items live in the location returned by
    FSFindFolder(kLocalDomain, kApplicationSupportFolderType).

    If you decide to use Mac OS X APIs to maintain the data, you want to look into
    the CFPrerences API. If you are setting per-user preferences, use
    kCFPreferencesCurrentUser, otherwise use kCFPreferencesAnyUser.

    Note that there is no API that covers application support items -- this is
    because application support items are considered to be completely managed by the
    application itself. Therefore, if you decide that your data belongs in
    application support (which I don't think is right because on the little you've
    said so far), you have to take care of reading and writing the file yourself.

    If you maintain the file yourself, I recommend you name it with the
    com.company.product convention (see /Library/Preferences for examples).

    hth

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

  3. #3

    Default Re: INI files? Porting from XP to OS X

    Hi!

    Thank you for your very-very informative reply!
    I'll choose to maintain the file by OS X API, just like I did on
    Windows/WinAPI, IniFile.

    Regards and thanx again,
    Greg


    "Miro Jurisic" <org> wrote in message
    news:mit.edu... 
    wrote: [/ref]
    applications. 
    Mac. [/ref]
    driver [/ref]
    with the [/ref]
    can't 
    >
    > The reason you can't put it inside the app is that you can't assume you[/ref]
    have the [/ref]
    must [/ref]
    place 
    >
    > You need to decide whether this file contains:
    >
    > a. preferences
    > b. application support resources
    >
    > A preferences file is something that I would feel sad about losing,[/ref]
    because it 
    it out, 
    different 
    at 
    for it, 
    using a 
    FSFindFolder(kUserDomain, 
    FSFindFolder(kLocalDomain, 
    into 
    by the 
    you've 
    yourself. 


    Greg Guest

  4. #4

    Default Re: INI files? Porting from XP to OS X

    In article <bov8fm$1u2$matavnet.hu>,
    "Greg X" <com> wrote:
     

    Please read:
    <http://developer.apple.com/macosx/win32porting/>
     

    Writing a device driver on Mac OS X is NOT for the faint of heart. If
    you have no device driver experience on Mac OS X, leave a lot of time
    for it in your schedule. What kind of device is it? You may not need a
    driver.
     

    Drivers cannot read/write to disk. You will need to pass the data to
    your kext from userland.
     

    What's a Windows INI file? (Why do people asking about porting always
    assume we are Windows experts...) What kind of info is in this file?
    Sean Guest

  5. #5

    Default Re: INI files? Porting from XP to OS X

    Hi!
     

    Ah, great! Thanx!
     

    Well, I've already made a basic working PCI driver on OS X.
    It is pretty well understandable after Windows (WDM) kernel driver
    development.
    Anyway, there are many functionalities of the driver which I didn't port
    yet, because
    I first want to get more experience on OS X.

    Currently I have a lot more trouble with applications having user
    interfacaces.
    This very different from what I know..
     

    Oh.. It sounds bad.
    You know my driver is a stand-alone driver which can interact with
    applications,
    but must work well on its own, without any helper application.

    This is the same on Windows, a kernel driver can't safely (and shouldn't at
    all) access
    files, but it can safely start a "worker queue" at level=0/user level which
    can do anything.

    Something like this:
    Kernel: Hey user level worker! I'm a kernel driver and I need data from this
    FILE and put it into my MEMORY HERE. Tell me when it is here, I won't wait
    for you!
    Worker: Ok, I'll let you know as soon as I have loaded the data from the
    HDD/FILE into your MEMORY.
    ....a little bit later:
    Worker: Hey kernel driver! The stuff you wanted is already there where you
    told me to put it!
    Kernel: Starts to use the loaded data without problems.

    So, this all is one SYS file on Windows, just a single kernel driver which
    starts a user level worker queue thread.
    Is this possible with a kext? Can a kext start a user level thread which
    will do the job and tells when it is ready?
    ...without a helper application of course.
     

    ...because there are only people with PCs around me. I'm the only one in my
    area who has a Mac (and a PC).
    So, it isn't typical for me if someone doesn't know PCs.
    Macs are a lot more charmy and interesting anyway ;)
     

    Well, I simplified the problem a lot!
    This PCI card is actually an interface/controller card which controls
    external devices real-time and works with
    about ~100-~150 templates which are all in small files.
    Like I said before, this is a standalone driver which must work on its own,
    even if it has the ability to interact with user applications.
    A typical user application which it interacts with is the template editor
    for the driver.
    If(!!!) you run this application, you can edit some or all of the templates
    and it tells the driver to refresh the modified templates.
    It can be made from the HDD (with worker queues) or by a shared object, it
    doesn't really matter, since if this application doesn't
    run, the driver still needs to be able to load all the templates for itself
    from the HDD.

    I guess you understand my situation more than before.
    So, is there anything as a worker queue in kexts?

    Thanx for your reply!
    Greg


    Greg Guest

  6. #6

    Default Re: INI files? Porting from XP to OS X

    In article <bovkhj$5ao$matavnet.hu>, "Greg X" <com> wrote:
     

    You should check what the status of using any of my advice is if you are in a
    KEXT. I suspect the answer will be that you can't use those APIs from a driver,
    so you'll have to come up with a way to communicate with userland code, but I am
    not a driver developer so I can't tell you how to do that.

    hth

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

  7. #7

    Default Re: INI files? Porting from XP to OS X

    > You should check what the status of using any of my advice is if you are
    in a 
    driver, 
    but I am 

    Sure, I'll learn about those things before implementing anything.
    BTW, what free tool do you recommend for making multi-window applications?
    - Put down a checkbox
    - Put down a button
    - Doubleclick on the button and write code for its onclick inplace
    - Write to onlcik: checkbox.checked = true
    - etc...

    Is there any free tool like this?

    Thank you for your replies!
    Greg


    Greg Guest

  8. #8

    Default Re: INI files? Porting from XP to OS X

    "Greg X" <com> wrote:
     

    The MDI etc. paradigm only exists on that other Platform B-)
     

    You have the choice between Project Builder and Project Builder (OK, we
    could argue you might also use puse Java which opens the field for
    Eclipse etc.).
    While the tool is "free" as you are not charged for it it will cost you
    something in the dimensions of a week of work and a decent Cocoa book to
    get up and running with the PB / IB / Objective C / Cocoa concepts.

    --
    This address is valid in its unmodified form but expires soon.

    Thomas Guest

  9. #9

    Default Re: INI files? Porting from XP to OS X

    > You have the choice between Project Builder and Project Builder (OK, we 

    Ok, and what is right commercial tool to use for a job like this?


    Greg Guest

  10. #10

    Default Re: INI files? Porting from XP to OS X

    In article <bp2b3b$1jqdet$news.uni-berlin.de>,
    Thomas Engelmeier <com> wrote:
     

    To clarify this, actually Interface Builder is the tool to do GUIs.
    Project Builder is simply the IDE that manages your files and
    compiles/links them.
     

    Not quite accurate, he can of course also use PB/IB to create a Carbon
    application (and NIB files describing the GUI for said Carbon app), but
    as a former Carbon developer, I would encourage the OP to learn Cocoa.
    There's a good book by Aaron Hillegass on Cocoa programming, which lets
    you learn the basics in a weekend. Maybe more if you're not familiar
    with the Mac, maybe less if you're good at OOP.

    Carbon is a "straight C" API, and is the equivalent to the low-level
    Win32 stuff. However, Cocoa is a lot easier to use than Carbon if you're
    building GUI applications (at this point -- Carbon is catching up more
    and more each OS release), and since Objective C is a superset of C
    (more so than C++, actually), you can easily use your C (and even C++
    code) from inside your Objective C code.

    As to MDI vs. SDI: To put it in a simplified way, the Mac only has MDI.
    You typically don't launch multiple instances of the same application on
    Mac OS. So, if you need that part of SDI, you will have to rework your
    design (for GUI applications -- you can launch as many copies of a
    Unix-style daemon as you want, of course). The Mac's MDI looks different
    than Windows', e.g. you don't usually have a "root window", you have the
    menu bar at the top of the screen, etc.

    "Greg X" wrote: 

    Check out Interface Builder. Checkboxes will automatically
    check/uncheck on the Mac, so you won't need to write any
    mouseDown:/kEventControlHit code for that. You just drag the stuff into
    a window from a palette and it works.

    In Carbon, you give each object a control ID that you can use to look
    up the control in its window at runtime. You also need to write code to
    load and show the window (two or three API calls) and install "carbon
    event handler" callback functions to be notified of clicks in
    pushbuttons, changes in edit fields etc.

    In Cocoa, you name the file in a special way and it'll be automatically
    loaded. Then you add "outlets" (pointers that are automatically filled
    out when the window is loaded) to your class and connect buttons, fields
    etc. to methods of your class. Then you just choose a menu item to
    create a source file that declares your class (or adds your changes to
    the existing class) and fill it out with your actual code.

    The template projects that come with Project Builder already contain
    some sample code which you can try out.
     

    Pretty much the only deal in town if you want a commercial tool is
    CodeWarrior from Metrowerks.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
    Uli Guest

  11. #11

    Default Re: INI files? Porting from XP to OS X

    In article <bp0eoe$e68$matavnet.hu>,
    "Greg X" <com> wrote:
     

    It might be *possible* but you would definately be doing things
    backwards and will likely have lots of trouble. The paradign on OS X is
    the other way around. It is userland that tells the driver "do this",
    not vice versa.
     

    Well, I would suggest creating an IOUserClient in your kext to respond
    to requests from this and any otehr userlevel app that talks to your
    driver.

    You will need a userland app that reads your 'config file' and sends
    this info to your driver. You could do this in a "startup item" or
    "login item", so that when the Mac starts/or a user logs in, your driver
    is given the data it needs to begin its work.
    Sean Guest

  12. #12

    Default Re: INI files? Porting from XP to OS X

    Hi!
     

    I've already used Interface Builder. It is just like a Resource Editor
    (resource workshop) for Windows.
    I need an IDE/RAD tool which doesn't force me to create separate resources
    and separate code.
    I'd like to put down a button, double-click on it right on the interface
    builder,
    then write the code inplace for its click.
    This is the kind of a development tool I'm searching for. (like
    Kylix/Delphi/MSVC++/etc..).

    Which devtool works like this on Mac OS X?
     

    Yes, this is what I'd like to avoid. I'll have fairly much work even if I
    won't have
    to write code for stuff like this manually.
     

    This sounds much better! Thanx.
    Anyway, if you know something even more comfortable, please tell me.
    (like Kylix/Delphi/MSVC++)
     

    Thanx, I'll check out Cocoa examples if there is any. (I hope there is ;)
     

    Ah, maybe this is the tool which will be like Kylix/Delphi/MSVC++ !

    Thank you for the infos.
    Greg


    Greg Guest

  13. #13

    Default Re: INI files? Porting from XP to OS X

    In article <bp4nug$nlo$matavnet.hu>,
    "Greg X" <com> wrote:
     
    >
    > I've already used Interface Builder. It is just like a Resource Editor
    > (resource workshop) for Windows.[/ref]

    No. In fact it's very little like a resource editor for Windows.
     
    >
    > Ah, maybe this is the tool which will be like Kylix/Delphi/MSVC++ ![/ref]

    Nope.
    Gregory Guest

  14. #14

    Default Re: INI files? Porting from XP to OS X

    "Greg X" <com> wrote:
     
    >
    > Ok, and what is right commercial tool to use for a job like this?[/ref]

    Codewarrior from Metrowerks ist the C / C++ environment comparable to
    Project Builder. However, it has no perfect alternative but kind of
    integrates with Interface Builder.

    Another tool worth evaluating is Real Basic. It offers a neat IDE but
    unfortunately you probably need to create an (C / C++) based plugin for
    it to communicate with your driver.


    Regards,
    Tom_E

    --
    This address is valid in its unmodified form but expires soon.

    Thomas Guest

  15. #15

    Default Re: INI files? Porting from XP to OS X

    In article <bp4nug$nlo$matavnet.hu>, "Greg X" <com> wrote:
     

    For C++, none whatsoever. I already mentioned RealBasic.

    hth

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

  16. #16

    Default Re: INI files? Porting from XP to OS X

    In article <bp4nug$nlo$matavnet.hu>,
    "Greg X" <com> wrote:
     
    >
    > Thanx, I'll check out Cocoa examples if there is any. (I hope there is ;)[/ref]

    I can't mention this often enough: Get the book on Mac OS X Programming
    with Cocoa by Aaron Hillegass. It's good. It teaches you most of the
    stuff you'll need, and the rest you can glean from Apple's reference
    docs. One weekend and the price of the book, plus PB/IB which are free
    from Apple. That's all it takes.
     
    >
    > Ah, maybe this is the tool which will be like Kylix/Delphi/MSVC++ ![/ref]

    CodeWarrior comes with PowerPlant, which is a C++ application
    framework. I haven't tried it in a while, but I doubt it works the way
    you described. PB/IB (or, if you have MacOS X 10.3 xCode/IB) will
    probably be your best choice in that case, with Cocoa.

    However, as opposed to what Tom_E is saying, if you're doing Carbon
    development, there's not much difference between CodeWarrior and Project
    Builder/xCode. You *can* use PB for Carbon development just fine. And
    you can use IB in Carbon as well, it's just not as nicely integrated as
    with Cocoa. Actually, I wouldn't do a new Carbon project without IB
    these days.

    If you're using CodeWarrior's PowerPlant framework, it'll probably be
    C++ier than straight Carbon, though. But if you don't want PP, it'll be
    pretty much the same experience. CodeWarrior used to be more
    streamlined, but these days PB and CW are pretty close in that regard.
    And since PB is from Apple, it's better integrated with the OS and IB,
    and it's more likely that there's a current version available.

    Cheers,
    -- Uli
    Uli Guest

  17. #17

    Default Re: INI files? Porting from XP to OS X

    In article <bp4nug$nlo$matavnet.hu>,
    "Greg X" <com> wrote:
     

    There isn't really such a tool for professional application development
    on the Mac these days. There are lots of tools that do this, but they
    usually include insanely large runtimes, and they use their own
    programming languages. Most of them support plugins coded in C to extend
    them, but I don't think that's what you want for driver development.
    E.g.:

    -> RealBASIC - Like Visual BASIC, but I heard recent versions were
    rather buggy
    -> Runtime Revolution - A cross-platform tool that runs on Mac, Win,
    Unix and the kitchen sink. The design is a little unixy (though they
    fixed the GUI of the IDE to be more Windows-ish)
    -> SuperCard - A predecessor of RunRev that comes from the Mac. Not
    cross-platform, hence a much better GUI in the built apps.
    -> There used to be AppMaker, which was kind of a glorified
    code-generator, but I'm not sure it made the jump from MacOS 9 to X
     
    >
    > This sounds much better! Thanx.
    > Anyway, if you know something even more comfortable, please tell me.
    > (like Kylix/Delphi/MSVC++)[/ref]

    Just one warning: Cocoa is based on Objective C, a cross between C and
    Smalltalk. It is very easy to learn, since it consists of about six
    extensions to C or so, but it looks kind of weird, which frightens many
    people away.

    There's also a Java version of Cocoa, but I'd advise against it, since
    it was built by simply putting a "Java Bridge" on top of the existing
    Cocoa frameworks, which has its quirks.
     
    >
    > Thanx, I'll check out Cocoa examples if there is any. (I hope there is ;)[/ref]

    There are. There's also a sample code section at http://www.apple.com/developer

    Cheers,
    -- Uli
    http://www.zathras.de
    Uli Guest

  18. #18

    Default Re: INI files? Porting from XP to OS X

    Hi!

    Thanx for your suggestions!
    I'll try out as many as I can, then I'll decide depending on my own
    experiences.
    You know, it is very confusing for me that I could make PCI driver four days
    after I met the first Mac in my life,
    but I still can't throw down some buttons, write code for them and run the
    app.
    This is totally different on Windows (sorry for mentioning again, but I have
    years of experience on that platform)
    It took me lots of time to be able to develop serious kernel mode real-time
    WDM PCI drivers on Windows,
    but even a beginner can me user applications with GUIs in 1 minute.
    Here, on Mac OS X, I was impressed how simple is to do things in kernel, but
    I'm completly lost with basic
    GUI applications which kind of development is a cakewalk on Windows.
    It seems like here beginners are writing their device drivers first, then
    they learn years to make their first GUI ;)

    I hope I'll find a cool development tool for GUI apps.
    Thanx again!
    Greg


    Greg Guest

  19. #19

    Default Re: INI files? Porting from XP to OS X

    Miro Jurisic <org> wrote:
     
    >
    > For C++, none whatsoever. I already mentioned RealBasic.
    >
    > hth
    >
    > meeroh[/ref]
    There was something to prototype applications in Real Basic and
    generate metrowerks code from the results, [devdepot.com had a special
    on this combo of stuff a while back] but I am not sure how it works with
    cw9. Never used it and do not know how well it really works, but last I
    knew it was available.
    It was in an add in mactech sometime earlier this year.
    Carl Guest

  20. #20

    Default Re: INI files? Porting from XP to OS X

    In article <bp7atf$jhv$matavnet.hu>,
    "Greg X" <com> wrote:
     

    Using Project Builder/Xcode and Interface Builder, you can write a
    reasonably complete web browser without writing a single line of code.
    They may not be as completely integrated and funky as something like
    Visual C++, but it is still very easy to make nice GUIs. You just have
    to put a bit of effort into learning them.
    Michael Guest

Page 1 of 3 123 LastLast

Similar Threads

  1. Porting from CS to 10... can it work?
    By JeffreyBower@adobeforums.com in forum Adobe Illustrator Windows
    Replies: 3
    Last Post: April 13th, 03:40 PM
  2. Help need to porting from MS SQL to DB2 8.1
    By James Hong in forum IBM DB2
    Replies: 5
    Last Post: September 25th, 09:29 AM
  3. porting to pc
    By cwf prod webforumsuser@macromedia.com in forum Macromedia Director Basics
    Replies: 1
    Last Post: August 12th, 02:56 PM
  4. Porting code to Mac
    By Stephen Fraser in forum Mac Programming
    Replies: 2
    Last Post: August 3rd, 04:16 PM
  5. Replies: 0
    Last Post: July 1st, 05:00 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139