bitpim-devel — For bitpim developers

[Bitpim-devel] Something to try (port speeds)

[Roger B. <ro...@ro...>]

Here is something to try for those of you using phones connected
via a USB to serial connection.  In com_brew.py at line 259, change
it to read:

  self.comm.write("AT$QCDMR=115200;AT$QCDMG\r\n")

In theory that should make the data rate for the diagnostics
protocol be 115200.  On my VX4400, I set the diag rate in
the service menu to 38400 (the default) and rebooted the
phone.

Despite the phone responding OK to the above request, the
diagnostics still only operated at 38400.  The other phones
I have are all straight USB where the baud rate is irrelevant.
However maybe it will work for a different phone.  (The goal
is to have the phone automatically operate at the higher speed
if possible without users having to reconfigure it).

(I also tried putting the request on two seperate lines and
still got OK for both, and the phone still didn't do what it
ok'ed).

Roger

Re: [Bitpim-devel] Audiovox CDM 8900

[Roger B. <ro...@ro...>]

Chris Fraser wrote:
> I've created a trace, and will send it to Roger. I'd post it here, but
> it has a phonebook dump in it. ;)

Thanks to Calvin, I got it up and working as well.  Something that would be
very useful for this phone is how the ringtone and wallpapers are done.
My phone doesn't actually have a live line, and I don't want to pay to 
send/receive several in order to figure it out.

Roger

RE: [Bitpim-devel] Audiovox CDM 8900

[Chris F. <cf...@za...>]

I've created a trace, and will send it to Roger. I'd post it here, but
it has a phonebook dump in it. ;)

Chris...

On Mon, 22 Mar 2004, Calvin Martini wrote:

> The Curitel application that was used to communicate with the CDM8900
> was the one for the TX95C found at the following link:
>
> http://www.curitel.com/english/download/pcsynch.asp
>
> I don't have a CDM8900 and can't grab the traces for you, but this app
> should at least communicate. Warning: Do not write to your phone using
> this application - apparently it corrupts your phone if you do (a slight
> difference in the phone book format).
>
> Best regards,
>
> Calvin

RE: [Bitpim-devel] Audiovox CDM 8900

[Calvin M. <mar...@ro...>]

>>From one of the Hofo threads, people claimed to be able to talk to the
phone
>>using the Curitel sync application.  However that app doesn't work for
me.
>>(I downloaded the version for the PD-K500).  From the portmon sniff,
it
>>puts the phone into DM mode, and then sends command zero, gets a
result
>>and puts up a dialog box in Korean.  I assume it doesn't like the
result
>>which is firmware information.

The Curitel application that was used to communicate with the CDM8900
was the one for the TX95C found at the following link:

http://www.curitel.com/english/download/pcsynch.asp

I don't have a CDM8900 and can't grab the traces for you, but this app
should at least communicate. Warning: Do not write to your phone using
this application - apparently it corrupts your phone if you do (a slight
difference in the phone book format).

Best regards,

Calvin

Re: [Bitpim-devel] Audiovox CDM 8900

[Roger B. <ro...@ro...>]

> that is accessable by issuing "##7678<END>" (##PORT). You can also control

That was fun to play with :-)

From one of the Hofo threads, people claimed to be able to talk to the phone
using the Curitel sync application.  However that app doesn't work for me.
(I downloaded the version for the PD-K500).  From the portmon sniff, it
puts the phone into DM mode, and then sends command zero, gets a result
and puts up a dialog box in Korean.  I assume it doesn't like the result
which is firmware information.

If anyone does have a working setup, I would appreciate some protocol
traces.  Grab the portmon application from sysinternals.com.  Ensure
Capture -> Ports includes all ports on the phone.  Under Options, ensure
show hex is turned on.  Under edit, ensure Max Output Bytes is set
to 4096.

My goal is try and determine if there is an actual sync protocol for
this phone, or if the "correct" way really is to read and write the
files directly off the phone.

Roger

Re: [Bitpim-devel] Audiovox CDM 8900

[Chris F. <cf...@za...>]

I wanted to share some information I just discovered.

The reason you can't use the diagnostic port on the CDM-8900 is that it
appears to be set to "UART MAIN" as a factory setting. I was playing
around with ## commands today, and stumbled upon the "RunTime DevMap" menu
that is accessable by issuing "##7678<END>" (##PORT). You can also control
the DM Mode port speed by issuing "##2283<END>" (##BAUD). I changed the diag
setting in the "RunTime DevMap" menu to "USB DIAG" and I can now
successfully connect to the phone through the diagnostic port. The
connections to the phone over the diagnostic port appear to happen with
less negotiation as well. Of course it could just be my perception.

Not sure if this helps anyone, but it seemed like an interesting tidbit of
info.

Chris...

Re: [Bitpim-devel] LG VX6000-IN DETAIL WHAT DO I DO NEXT? HOW?

[Roger B. <ro...@ro...>]

DRE...@ao... wrote:
> An unexpected exception has occurred.
> Please see the help for details on what to do.

Please do what was requested the last time you posted:

  From: "Roger Binns" <ro...@ro...>
  To: <bit...@li...>
  Subject: Re: [Bitpim-devel] LG VX6000- RINGTONES
  Date: Sat, 13 Mar 2004 19:10:03 -0800

  Please read ALL of the following links and then post your question
  again.

     http://www.catb.org/~esr/faqs/smart-questions.html

     http://bitpim.sourceforge.net/testhelp/trouble-serial.htm

     http://bitpim.sourceforge.net/testhelp/support.htm

For example, you haven't included the version of BitPim, you have posted
to an inappropriate list, you haven't included the log, you haven't 
included which port you used and the details from that, no details
on why you didn't use auto ports, no details on what you were doing
at the time etc etc.

Roger

[Bitpim-devel] LG VX6000-IN DETAIL WHAT DO I DO NEXT? HOW?

[<DRE...@ao...>]

An unexpected exception has occurred.
Please see the help for details on what to do.

Traceback (most recent call last):
  File "gui.pyo", line 150, in run
  File "gui.pyo", line 91, in __call__
  File "gui.pyo", line 1052, in getdata
  File "gui.pyo", line 1046, in getfundamentals
  File "com_lgvx4400.pyo", line 89, in getfundamentals
  File "com_brew.pyo", line 201, in getfilecontents
  File "com_brew.pyo", line 283, in sendbrewcommand
  File "com_phone.pyo", line 102, in setmode
  File "com_brew.pyo", line 239, in _setmodebrew
  File "com_brew.pyo", line 331, in sendbrewcommand
IndexError: string index out of range

Variables by last 8 frames, innermost last

Frame getdata in gui.pyo at line 1052
           self =  <WorkerThread(BitPim helper, started daemon)>
            req =  <guiwidgets.GetPhoneDialog instance; proxy of C++ wxDialog 
i

Frame getfundamentals in gui.pyo at line 1046
           self =  <WorkerThread(BitPim helper, started daemon)>
        results =  {}

Frame getfundamentals in com_lgvx4400.pyo at line 89
           self =  <com_lgvx6000.Phone instance at 0x01E35F58>
        results =  {}

Frame getfilecontents in com_brew.pyo at line 201
           self =  <com_lgvx6000.Phone instance at 0x01E35F58>
            req =  <p_brew.readfilerequest object at 0x01E14610>
          start =  1079483503.25
           file =  'nvm/$SYS.ESN'
           data =  <cStringIO.StringO object at 0x01E145A0>
           desc =  'Reading nvm/$SYS.ESN'

Frame sendbrewcommand in com_brew.pyo at line 283
    callsetmode =  True
        request =  <p_brew.readfilerequest object at 0x01E14610>
           self =  <com_lgvx6000.Phone instance at 0x01E35F58>
  responseclass =  <class 'p_brew.readfileresponse'>

Frame setmode in com_phone.pyo at line 104
    desiredmode =  'modebrew'
           self =  <com_lgvx6000.Phone instance at 0x01E35F58>
        strmode =  'none'
 strdesiredmode =  'brew'
           func =  '_setmodebrew'
              v =  'writefile'

Frame _setmodebrew in com_brew.pyo at line 242
           self =  <com_lgvx6000.Phone instance at 0x01E35F58>
            req =  <p_brew.memoryconfigrequest object at 0x01E14650>
          respc =  <class 'p_brew.memoryconfigresponse'>

Frame sendbrewcommand in com_brew.pyo at line 331
       origdata =  'Y\x0c\xc4\xc1~'
              d =  0
  responseclass =  <class 'p_brew.memoryconfigresponse'>
         buffer =  <prototypes.buffer instance at 0x01E41148>
        request =  <p_brew.memoryconfigrequest object at 0x01E14650>
    callsetmode =  False
       firsttwo =  'Y\x0c'
            crc =  '\xc4\xc1'
           data =  'Y\x0c'
           self =  <com_lgvx6000.Phone instance at 0x01E35F58>

Re: [Bitpim-devel] Samsung A620 - small update

[Roger B. <ro...@ro...>]

> - This appeared briefly to work.  The first time it retried, it would get
> unstuck.  However, it would then give me a bad size exception.  

None of the LG phones use the retry code.  I initially added it to try
and work around the VX4400 USB issues, then removed it, and then it
got re-added.  I think Stephen uses it for some of the Sanyo phones.
The big problem is that retries are only useful for stateless stuff.
If for example you send a command like 'advance to next entry' and
get a timeout reading the response, how do you know if the action
happened or not?  The sensible precaution is to start over again,
but usually you would hit the same issue in the same place or
earlier.

> - Finally, I switched USB drivers, and I was able to go from reading 10-15
> files from the filesystem to a full set of 105 or so files.

There is a 0.3 second delay after getting each file when making a zip
backup.  I found some phones (cough LG cough) would eventually crap out.
I think their other tasks running on the phone getting starved for CPU
or something similar.

> Time to start poking at the files to see what I can find...

Wherever possible it is preferable to use the sync protocols rather
than modify the filesystem directly.

Roger

[Bitpim-devel] Samsung A620 - small update

[Mike B. <ma...@po...>]

So after days of fighting with timeout errors and blue screens of death
(from trying to work around the timeout errors), I have come to the
conclusion that the proper USB drivers are highly important. :)

I'm currently using a FutureDial cable ("For Samsung model A310, A600").

The first set of samsung drivers I tried to use were the boxwave drivers
found here:
http://www.boxwave.com/products/minisync/samsung/samsung_drivers.zip

These caused me no end of crashes and timeouts.

The new set of samsung drivers that I am using can be found here:
http://www.susteen.com/download/drivers/SamsungCQX.zip

These drivers let me backup the entire filesystem without a single timeout,
which enabled me to remove all of my flawed(?) timeout code.

Just a bit of learning experience, for everyone to possibly benefit from,
here's what I saw and tried before switching drivers:
- First, I was getting a timeout message.  It was consistently reading 198
bytes from a packet that listed the size as 256 bytes.
- To work around this, I changed sendbrewcommand locally to the following:
    def sendbrewcommand(self, request, responseclass, callsetmode=True,
numsendretry=2):
        if callsetmode:
            self.setmode(self.MODEBREW)
        buffer=prototypes.buffer()
        request.writetobuffer(buffer)
        data=buffer.getvalue()
        self.logdata("brew request", data, request)
        data=escape(data+crcs(data))+self.brewterminator
        firsttwo=data[:2]

        isendretry=numsendretry
        while isendretry>=0:
            try:
                self.comm.write(data, log=False) # we logged above
                data=self.comm.readuntil(self.brewterminator,
logsuccess=False)
                break
            except modeignoreerrortypes:
                if isendretry>0:
                    self.log("Resending request packet...")
                    time.sleep(0.3)
                else:
                    self.mode=self.MODENONE
                    self.raisecommsdnaexception("manipulating the
filesystem")
                isendretry-=1

        self.comm.success=True
        origdata=data

        # sometimes there is junk at the begining, eg if the user
	[...]

- This appeared briefly to work.  The first time it retried, it would get
unstuck.  However, it would then give me a bad size exception.  Comparing
the packets sent during a successful read of the file vs an unsuccesful
read, the *only* difference was that the second to last packet from the
phone set the "has more data" flag to false instead of true.  ARGH.
- I then tried, in this situation, to ignore the "has more data" flag and
force it to keep reading anyways.  This led very quickly to a blue screen of
death in my USB drivers.  ARGGGH.
- I then tried to override the getfilecontents function, and wrapped the
whole thing in a try/except block to try to force the entire file read to
restart.  Oddly enough, this also led very quickly to a blue screen of
death, though it's possile I didn't do it correctly.
- Finally, I switched USB drivers, and I was able to go from reading 10-15
files from the filesystem to a full set of 105 or so files.

Time to start poking at the files to see what I can find...

Mike

Re: [Bitpim-devel] Startup script for BitPim on Macs

[Tom P. <mlp...@ea...>]

On Mar 15, 2004, at 3:02 PM, Roger Binns wrote:
>>              if self.standalone or self.semi_standalone:
>>                  # XXX we're screwed when the end user has deleted
>>                  # /usr/bin/python
>>                  hashbang = "/usr/bin/python"
>
> Gives new meaning to "standalone".  Maybe they need a
> "reallystandaloneireallymeanitandnooptionaldependenciesthistimeplease" 
> :-)
> (I have been known to name variables/functions like that sometimes when
> experiencing a lot of frustration with other components).

Yes, I noticed.  MakeTheDamnThingRedraw() put a smile on my face when I 
ran across it.  It made me remember how glad I am not to be doing 
X11/Motif programming anymore...

Tom

Re: [Bitpim-devel] Startup script for BitPim on Macs

[Roger B. <ro...@ro...>]

>              if self.standalone or self.semi_standalone:
>                  # XXX we're screwed when the end user has deleted
>                  # /usr/bin/python
>                  hashbang = "/usr/bin/python"

Gives new meaning to "standalone".  Maybe they need a 
"reallystandaloneireallymeanitandnooptionaldependenciesthistimeplease" :-)
(I have been known to name variables/functions like that sometimes when
experiencing a lot of frustration with other components).

Roger

Re: [Bitpim-devel] Startup script for BitPim on Macs

[Roger B. <ro...@ro...>]

> Not really.  I've been dealing with cross-platform Unix issues for most
> of my career, and know how to write a portable Bourne shell script that
> you can expect to run pretty much anywhere. 

Me too!  I used to work on machines that had multiple universes (as they
called it).  You could have a sysv environment or a bsd environment
with commands scattered between them, and lots of other fun issues.

> Sed and awk are always safe. 

They may always exist, but they don't necessarily always run with
non-trivial data.  Things like arbitrary limits on line length (such
as 512 or 1024 chars), breaking on any files not having UNIX end of
lines, limits on the number of variables etc.

> The main
> challenge is recognizing and avoiding shell features that are bash- or
> ksh-specific.  You might be surprised how much you can still do within
> these limitations.

Heck, I still don't use shell functions except when I occassionally 
remember they exist :-)  I ended up writing a macro system in TCL
that had a library of shell code, and then expanded it for the
main shell scripts.  It turned out to be very useful as there is
so much stuff that doesn't work between machines, even modern
ones (for example try killing one of your own processes named foo,
or finding out how much free disk space there is for a proposed
directory name).

> (Not a terribly vital job skill nowadays, unfortunately.)

It isn't the skill that matters, but more the way of thinking that
does.  I am glad that a lot of these lower level issues are non-issues
any more, while the thinking is still very relevant.  For example here
is another great programmer complaining about the very same issue:

   http://www.joelonsoftware.com/articles/PleaseLinker.html

Roger

Re: [Bitpim-devel] Startup script for BitPim on Macs

[Tom P. <mlp...@ea...>]

On Mar 15, 2004, at 2:16 PM, Steven Palm wrote:
>> In any case, I've attached a shell script that could be used to 
>> replace the current BitPim python startup script.  It uses a small 
>> shell function to extract the parent directory name from a filepath 
>> because the 'dirname' shell utility (like Python) is only there in 
>> MacOS X if the user installs the optional BSD package. Otherwise, 
>> it's just about line-for-line equivalent with the python version.
>
>  I'm not interested in removing the BSD subsystem from my computer to 
> test, but I see you state that `dirname` is not available unless you 
> install the BSD subsystem. You are using `sed`, however, so that one 
> *is* installed?

Yes, sed and awk are always installed on a minimal unix system.


> Given this kind of thinking, it's probably somewhat arbitrary what 
> commands Apple puts on your system as a CORE package versus the BSD 
> package, because I would land `sed` as a part of the BSD subsystem as 
> well, but it apparently is not.

It's understandable that this looks arbitrary to you, but it's not, 
really.  I was surprised that there was a 'dirname' utility at all, as 
soon as I saw it, because I know it's not standard.  That prompted me 
to check the Receipts directory to find which package it was installed 
with, and I found it was part of the BSD install.

(I have a perl script that lets you search your Receipts to see who 
installed what, if that sounds useful.  The Linux rpm system lets you 
ask questions like that easily, but I couldn't find anything for MacOS 
X that was comparable.  My perl script isn't really suitable for 
release, IMO, because it's kind of slow - it has to reread all of the 
receipts each time you run the script and that's an annoying delay.  It 
ought to cache that stuff somewhere, since it only rarely changes.)


> This makes it hard to be foolproof for future OS revisions as  well if 
> you write a shell script that depends on certain commands being there 
> (albeit minimal in this case.

Not really.  I've been dealing with cross-platform Unix issues for most 
of my career, and know how to write a portable Bourne shell script that 
you can expect to run pretty much anywhere.  (Not a terribly vital job 
skill nowadays, unfortunately.)  Sed and awk are always safe.  The main 
challenge is recognizing and avoiding shell features that are bash- or 
ksh-specific.  You might be surprised how much you can still do within 
these limitations.


Cheers,

Tom

Re: [Bitpim-devel] Startup script for BitPim on Macs

[Steven P. <n9...@n9...>]

On Mar 15, 2004, at 8:14 AM, Tom Pollard wrote:
> In any case, I've attached a shell script that could be used to 
> replace the current BitPim python startup script.  It uses a small 
> shell function to extract the parent directory name from a filepath 
> because the 'dirname' shell utility (like Python) is only there in 
> MacOS X if the user installs the optional BSD package. Otherwise, it's 
> just about line-for-line equivalent with the python version.

  I'm not interested in removing the BSD subsystem from my computer to 
test, but I see you state that `dirname` is not available unless you 
install the BSD subsystem. You are using `sed`, however, so that one 
*is* installed? Given this kind of thinking, it's probably somewhat 
arbitrary what commands Apple puts on your system as a CORE package 
versus the BSD package, because I would land `sed` as a part of the BSD 
subsystem as well, but it apparently is not. This makes it hard to be 
foolproof for future OS revisions as  well if you write a shell script 
that depends on certain commands being there (albeit minimal in this 
case.

Re: [Bitpim-devel] Startup script for BitPim on Macs

[Steven P. <n9...@n9...>]

On Mar 15, 2004, at 10:41 AM, Tom Pollard wrote:
> I didn't realize that.  I'd also be disinclined to muck with 
> bundlebuilder.py unless there was some stronger reason than this.  
> Maybe if the issue comes up again I'll lobby the bundlebuilder 
> maintainer to accept this change.  Just on technical grounds, it seems 
> clearly the right way to go.  Anyway, thanks for being willing to 
> discuss it.

  Just an aside.... I was looking through bundlebuilder.py just now to 
see if this could be remedied easily enough, and it appears that it 
might be do-able...  But you have to love this bit of code 
(particularly the comment):

             if self.standalone or self.semi_standalone:
                 # XXX we're screwed when the end user has deleted
                 # /usr/bin/python
                 hashbang = "/usr/bin/python"

... yes we are. :-)

Re: [Bitpim-devel] Startup script for BitPim on Macs

[Steven P. <n9...@n9...>]

On Mar 15, 2004, at 10:41 AM, Tom Pollard wrote:
>>> the user to have a separate, working Python installation.  From the 
>>> recent problem report on the bitpim-user list, we saw that Python is 
>>> an optional install on MacOS X.  The BitPim startup script doesn't 
>>> do anything that you can't do just as easily with a shell script, 
>>> and a shell script would remove the need for a working Python on the 
>>> user's machine.
>>
>>  An optional install, yes, but one that is marked by default on every 
>> installation. So, unless a user intentionally goes out of their way 
>> when doing the install or upgrade to make it NOT install, it will be 
>> there.
>
> If it's optional, it's optional.  Running ordinary apps under MacOS X 
> doesn't require its presence.  My understanding is that it's mainly 
> there to support Terminal users and Unix geeks.  If it was my 
> company's product, I'd insist on taking this simple step to make sure 
> my app ran on a minimal install of the OS.

  Well, look at it this way... If you intentionally choose to not 
install that piece, then you choose to break things that might depend 
on it. So yes, you have that choice, but there are consequences for it. 
I don't know what else you would also potentially break, but it's easy 
enough to simply put in the requirements of your software program that 
you require the BSD subsystem be installed. I'd liken the 'optional' 
but here to also say that printer drivers are optional, and you don't 
have to install them... Now, is it up to the application developer to 
figure out that you didn't and somehow work around that? Maybe a far 
stretch, but similar in the vein that the user took some intentional 
action to remove a part of the standard install.

  Now, if this were a company product where real money was being charged 
for it and there were a compelling reason to make it as idiot proof as 
possible, despite what the users may have done to their system, then 
I'd agree with you and would be compelled to try to make it work. 
However, that is not the case, and there are design decisions to use 
the base or common denominator of a standard set of components on top 
of a standard install of the operating system with it's default 
options. Just my opinion, anyway.

  I'm not intimately familiar with Python, this is the first time I've 
worked with it. However, after discussing things on the PythonMac 
mailing list, it came out that bundlebuilder.py was the way to generate 
a bundle. It doesn't mean it's the best, or the most fool-proof, etc... 
So the options are possibly open for an alternative, nobody can be 
aware of every alternative way to do something, no more than they can 
know every conceivable end-user configuration they'll be running 
against. If they could, I suppose we'd have no bugs or errors in 
shipping code. :-)

> Anyway, thanks for being willing to discuss it.

  Always open here, I don't claim to have any lock on the best way to do 
things (if there is one, opinions abound...) and can always learn 
something new and useful.

[Bitpim-devel] An update to the TM520 code

[Chris P. <dev...@te...>]

I will submit the whole file (com_lgtm520.py and p_lgtm520.p)
Hopefully attachment will work - the only missing piece is moving
an entry to a different speed-dial.

Re: [Bitpim-devel] Startup script for BitPim on Macs

[Roger B. <ro...@ro...>]

> I have no idea what the state of 'freeze' on Macs is, to be honest -
> I'm a python newbie.  (I do use ActiveState's 'PerlApp' under Windows
> and the open-source 'PAR' package under Unix (including MacOS X) for
> packaging Perl scripts as executables.)

For BitPim we do use different tools on each platform, as they all have 
different strengths and weaknesses.  It is definitely a goal that there
should be no need for anything to be already installed by the user.
That goal is met 100% on Windows and Linux.

On Windows Python itself is a DLL.  py2exe produces a zip of all your
.py code, and then has a stub executable that loads the DLL, and sets
the zip as the code path.  (See python-dev group for some proposals
for Python automatically finding the zip, removing the need for even
the stub executable).

Since zip files as an import source were only introduced in Python 2.3,
that approach doesn't work with earlier versions.  On Linux we use
Python 2.2, and the cx_Freeze tool.  That packages up the Python binary
with the code appended to the file and stub code to set things up
right (ie similar to zip but using custom code and archive format)

I believe that all the mechanisms will move over to the zip method
but that will set the minimum supported Python version as 2.3.

We also make sure we use "standard" stuff, and don't modify any other
components.  For example I could install Python 2.3 on Linux and
base everything off that, but that would be a non-standard installation.

Similarly we could benefit from moving up to the developer version
of wxPython+wxWidgets.  As Steven can tell you, I don't do that either :-)

If in your opinion something can be done better, then please contribute 
that to the necessary place (in this case whoever makes bundlebuilder).
Also be very aware that there may be good reasons why they did things
the way they did.  Also be aware that they may be concerned about backwards
compatibility (eg working with both Jaguar and Panther).  But this is
what open source is about - you get the best from everyone rather than
one what secretive arbitrary team of people make.

Roger

Re: [Bitpim-devel] Startup script for BitPim on Macs

[Michael C. <ma...@ca...>]

On 3/15/04, Tom Pollard posited:

>
>On Mar 15, 2004, at 10:59 AM, Steven Palm wrote:
>>
>>An optional install, yes, but one that is marked by default on every
>>installation. So, unless a user intentionally goes out of their way
>>when doing the install or upgrade to make it NOT install, it will be
>>there.
>
>If it's optional, it's optional.  Running ordinary apps under MacOS X
>doesn't require its presence.  My understanding is that it's mainly
>there to support Terminal users and Unix geeks.  If it was my
>company's product, I'd insist on taking this simple step to make sure
>my app ran on a minimal install of the OS.

Ah, if only more 'software professionals' were this professional about
their work! Back when I had a software company, I could have used as
many of you as I could get!

>I didn't realize that.  I'd also be disinclined to muck with
>bundlebuilder.py unless there was some stronger reason than this.
>Maybe if the issue comes up again I'll lobby the bundlebuilder
>maintainer to accept this change.  Just on technical grounds, it seems

Dang, where were you when I was hiring? Probably still in grade school
;-)
--=20
Mike Casteel
ma...@ca...                   Seattle, WA

Re: [Bitpim-devel] Startup script for BitPim on Macs

[Tom P. <mlp...@ea...>]

On Mar 15, 2004, at 10:59 AM, Steven Palm wrote:
>> I'm not sure how things are done on the other platforms, but I would 
>> have expected you to use the 'freeze' system for packaging a  script 
>> as a standalone executable, similarly to 'perl2exe' and it's ilk.
>
>  Except, as far as I know, that does not work properly on MacOS X. 
> Prove me wrong, I won't mind. ;^

I have no idea what the state of 'freeze' on Macs is, to be honest - 
I'm a python newbie.  (I do use ActiveState's 'PerlApp' under Windows 
and the open-source 'PAR' package under Unix (including MacOS X) for 
packaging Perl scripts as executables.)


>> the user to have a separate, working Python installation.  From the 
>> recent problem report on the bitpim-user list, we saw that Python is 
>> an optional install on MacOS X.  The BitPim startup script doesn't do 
>> anything that you can't do just as easily with a shell script, and a 
>> shell script would remove the need for a working Python on the user's 
>> machine.
>
>  An optional install, yes, but one that is marked by default on every 
> installation. So, unless a user intentionally goes out of their way 
> when doing the install or upgrade to make it NOT install, it will be 
> there.

If it's optional, it's optional.  Running ordinary apps under MacOS X 
doesn't require its presence.  My understanding is that it's mainly 
there to support Terminal users and Unix geeks.  If it was my company's 
product, I'd insist on taking this simple step to make sure my app ran 
on a minimal install of the OS.


> Also, it was not my design to build the bundle this way, I am using 
> the standard "bundlebuilder.py" routine that is part of the Python 
> distribtution and is, as far as I can tell, the accepted and 
> "approved" way to build distributable bundles on MacOS X. To wedge in 
> a different script would require gutting the work done by 
> bundlebuilder.py and making it a manual process each time.

I didn't realize that.  I'd also be disinclined to muck with 
bundlebuilder.py unless there was some stronger reason than this.  
Maybe if the issue comes up again I'll lobby the bundlebuilder 
maintainer to accept this change.  Just on technical grounds, it seems 
clearly the right way to go.  Anyway, thanks for being willing to 
discuss it.


Cheers,

Tom

Re: [Bitpim-devel] Startup script for BitPim on Macs

[Steven P. <n9...@n9...>]

On Mar 15, 2004, at 8:14 AM, Tom Pollard wrote:
> I'm not sure how things are done on the other platforms, but I would 
> have expected you to use the 'freeze' system for packaging a  script 
> as a standalone executable, similarly to 'perl2exe' and it's ilk.

  Except, as far as I know, that does not work properly on MacOS X. 
Prove me wrong, I won't mind. ;^)

> the user to have a separate, working Python installation.  From the 
> recent problem report on the bitpim-user list, we saw that Python is 
> an optional install on MacOS X.  The BitPim startup script doesn't do 
> anything that you can't do just as easily with a shell script, and a 
> shell script would remove the need for a working Python on the user's 
> machine.

  An optional install, yes, but one that is marked by default on every 
installation. So, unless a user intentionally goes out of their way 
when doing the install or upgrade to make it NOT install, it will be 
there.

> I've attached a shell script that could be used to replace the current 
> BitPim python startup script.  It uses a small shell function to 
> extract the parent directory name from a filepath because the 
> 'dirname' shell utility (like Python) is only there in MacOS X if the 
> user installs the optional BSD package. Otherwise, it's just about 
> line-for-line equivalent with the python version.

  Honestly, I'm not all that concerned about watching out for people who 
intentionally go into their installation process and remove things 
without knowing what they are doing. Also, it was not my design to 
build the bundle this way, I am using the standard "bundlebuilder.py" 
routine that is part of the Python distribtution and is, as far as I 
can tell, the accepted and "approved" way to build distributable 
bundles on MacOS X. To wedge in a different script would require 
gutting the work done by bundlebuilder.py and making it a manual 
process each time.

  Just my $0.02.

  If you think that your approach should be integrated into the 
bundlebuilder.py module as an alternative launch mechanism, perhaps it 
would be worthwhile joining the MacPython list (if you aren't already 
on it) and throwing it out there for discussion. It might be a useful 
option.

[Bitpim-devel] Startup script for BitPim on Macs

[Tom P. <mlp...@ea...>]

On Mar 15, 2004, at 12:00 AM, Roger Binns wrote:
> On Mar 15, Tom Pollard wrote:
>> Personally, I think that the startup script for BitPim should be a
>> shell script, rather than a Python script.
>
> You should discuss this on bitpim-devel.  On the other platforms, and
> I had believed Mac as well, the binary distribution of BitPim includes
> the Python interpretter and all modules needed (both ones written in
> Python and the necessary shared libraries).

I'm not sure how things are done on the other platforms, but I would 
have expected you to use the 'freeze' system for packaging a  script as 
a standalone executable, similarly to 'perl2exe' and it's ilk.  These 
systems package up the scripts, modules and dlls needed to run a script 
in a zip archive with a binary loader prepended.  The loader is 
responsible for unpacking things, setting up the environment and 
executing your script using the bundled interpreter.  This lets you run 
your script even if perl or python isn't installed at all on the target 
machine.

The way BitPim's packaged for the Mac is simpler; MacOS X makes it easy 
to do something along the lines of perl2exe without actually using a 
single zip archive with a binary loader.  But, you still need something 
like a loader to kick things off.  For BitPim, that's a small Python 
script.  This seems a little inelegant; since, this first script is the 
guy who sets things up so that subsequent python scripts can use the 
bundled python interpreter and modules, and so it requires the user to 
have a separate, working Python installation.  From the recent problem 
report on the bitpim-user list, we saw that Python is an optional 
install on MacOS X.  The BitPim startup script doesn't do anything that 
you can't do just as easily with a shell script, and a shell script 
would remove the need for a working Python on the user's machine.

Anyway, this is just a suggestion.  Most Mac BitPim users do seem to 
have Python installed.  In any case, I've attached a shell script that 
could be used to replace the current BitPim python startup script.  It 
uses a small shell function to extract the parent directory name from a 
filepath because the 'dirname' shell utility (like Python) is only 
there in MacOS X if the user installs the optional BSD package. 
Otherwise, it's just about line-for-line equivalent with the python 
version.

Cheers,

Tom

RE: [Bitpim-devel] Support for Kyocera 7135 (QC MSM5100)

[Stephen M. <sma...@sp...>]

Hi again, sorry my previous email address was using auto-reply SPAM
filters...
Here's a directory listing of my 7135...

----------------------------------------------------------------------------
--------------------
Kyocera 7135 (MSM5100)
MZ1044

ListFileRequest
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 00 Size: 00006  File:
uibuild.dir
Unknown1: 01 FF 00 01 03 Unknown2: 00 04 00 00 00 Size: 001DC  File:
$USER_DIRS
Unknown1: 01 FF 00 01 00 Unknown2: 00 02 00 00 00 Size: 00004  File:
$FIB_CHECKSUM
Unknown1: 01 FF 00 01 00 Unknown2: 00 08 00 00 00 Size: 00701  File:
$SYS_RMT
Unknown1: 01 FF 00 01 00 Unknown2: 00 02 00 00 00 Size: 00014  File:
$LINK_TIME
Unknown1: 01 00 00 FF 00 Unknown2: 00 02 00 00 00 Size: 00008  File:
$SYS_RMT_COUNT
Unknown1: 01 FF 00 01 00 Unknown2: 00 02 00 00 00 Size: 00173  File:
PRIData.txt
Unknown1: 01 FF 00 01 00 Unknown2: 00 40 00 00 00 Size: 03C76  File:
CarrierLogo.bmp
Unknown1: 01 FF 00 00 00 Unknown2: 00 02 00 00 0A Size: 0002C  File:
user/apps/UP4BCfg.dat
Unknown1: 01 FF 00 01 00 Unknown2: 00 02 00 00 0A Size: 000B0  File:
user/apps/UP4BBearer.dat
Unknown1: 01 FF 00 00 00 Unknown2: 00 02 00 00 0A Size: 00078  File:
user/apps/UP4BPerm.dat
Unknown1: 01 FF 00 00 00 Unknown2: 00 92 00 00 0A Size: 08C00  File:
user/apps/UP4BCache.dat
Unknown1: 01 FF 00 01 00 Unknown2: 00 02 00 00 0E Size: 00180  File:
user/contacts/user.dat
Unknown1: 01 FF 00 01 00 Unknown2: 00 02 00 00 0E Size: 0001D  File:
user/contacts/sys_pb
Unknown1: 01 FF 00 01 00 Unknown2: 00 02 00 00 0E Size: 00008  File:
user/contacts/user.idx
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 08 Size: 104E4  File:
ui/base/common.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 08 Size: 02E70  File:
ui/base/uirs.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0B Size: 07F78  File:
ui/lang/en/common.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0B Size: 095BC  File:
ui/lang/es/common.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0B Size: 09964  File:
ui/lang/fr/common.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0B Size: 09330  File:
ui/lang/pt/common.bqr
Unknown1: 01 37 00 01 03 Unknown2: 00 02 00 00 04 Size: 00061  File:
nvm/$SYS.ESN
Unknown1: 01 37 00 01 03 Unknown2: 00 02 00 00 04 Size: 000C1  File:
nvm/$SYS.INVAR1
Unknown1: 01 37 00 01 03 Unknown2: 00 02 00 00 04 Size: 00087  File:
nvm/$SYS.INVAR2
Unknown1: 01 FF 00 01 03 Unknown2: 00 02 00 00 08 Size: 00032  File:
nvm/nvm/nvm_0000
Unknown1: 01 FF 00 01 03 Unknown2: 00 02 00 00 08 Size: 0006B  File:
nvm/nvm/nvm_amps
Unknown1: 01 FF 00 01 03 Unknown2: 00 1C 00 00 08 Size: 01AD0  File:
nvm/nvm/nvm_display
Unknown1: 01 FF 00 01 03 Unknown2: 00 02 00 00 08 Size: 000C0  File:
nvm/nvm/nvm_security
Unknown1: 01 FF 00 01 03 Unknown2: 00 06 00 00 08 Size: 00553  File:
nvm/nvm/nvm_factory
Unknown1: 01 FF 00 01 03 Unknown2: 00 0E 00 00 08 Size: 00C81  File:
nvm/nvm/nvm_data
Unknown1: 01 FF 00 01 03 Unknown2: 00 04 00 00 08 Size: 002DF  File:
nvm/nvm/nvm_cdma
Unknown1: 01 FF 00 01 03 Unknown2: 00 08 00 00 08 Size: 0068B  File:
nvm/nvm/nvm_system
Unknown1: 01 FF 00 01 03 Unknown2: 00 02 00 00 08 Size: 00004  File:
nvm/nvm/nvm_serialport
Unknown1: 01 FF 00 01 03 Unknown2: 00 02 00 00 08 Size: 00007  File:
nvm/nvm/nvm_customer
Unknown1: 01 FF 00 01 03 Unknown2: 00 12 00 00 08 Size: 01006  File:
nvm/prl/prl_0000
Unknown1: 01 FF 00 01 03 Unknown2: 00 22 00 00 08 Size: 0200C  File:
nvm/prl/prl_0001
Unknown1: 01 FF 00 01 00 Unknown2: 00 02 00 00 08 Size: 0007F  File:
nvm/prl/eri1.bin
Unknown1: 01 FF 00 01 00 Unknown2: 00 02 00 00 08 Size: 0007F  File:
nvm/prl/eri.bin
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 05 Size: 021EB  File:
font/anlc12.bin
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 05 Size: 022ED  File:
font/anlcbd12.bin
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 05 Size: 00870  File:
font/arialtal.bin
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 05 Size: 017E3  File:
font/levbd12.bin
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 05 Size: 021EB  File:
font/levnm12.bin
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 05 Size: 00C15  File:
font/qicons12.bin
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00148  File:
apps/lang/pt/BreakOut.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00044  File:
apps/lang/pt/CalApp.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00210  File:
apps/lang/pt/CalcApp.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00294  File:
apps/lang/pt/ClockApps.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00044  File:
apps/lang/pt/MemoApp.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00358  File:
apps/lang/pt/QCOMControls.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 004E8  File:
apps/lang/pt/UP4BApp.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00114  File:
apps/lang/pt/WAPSetup.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 0012C  File:
apps/lang/fr/BreakOut.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00044  File:
apps/lang/fr/CalApp.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00210  File:
apps/lang/fr/CalcApp.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00270  File:
apps/lang/fr/ClockApps.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00044  File:
apps/lang/fr/MemoApp.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00364  File:
apps/lang/fr/QCOMControls.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00554  File:
apps/lang/fr/UP4BApp.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00134  File:
apps/lang/fr/WAPSetup.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00154  File:
apps/lang/es/BreakOut.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00044  File:
apps/lang/es/CalApp.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00280  File:
apps/lang/es/CalcApp.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00280  File:
apps/lang/es/ClockApps.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00044  File:
apps/lang/es/MemoApp.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00350  File:
apps/lang/es/QCOMControls.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 00528  File:
apps/lang/es/UP4BApp.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0D Size: 000E8  File:
apps/lang/es/WAPSetup.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0A Size: 00128  File:
apps/base/BreakOut.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0A Size: 00044  File:
apps/base/CalApp.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0A Size: 001E4  File:
apps/base/CalcApp.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0A Size: 0023C  File:
apps/base/ClockApps.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0A Size: 0030C  File:
apps/base/Launcher.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0A Size: 00044  File:
apps/base/MemoApp.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0A Size: 0033C  File:
apps/base/QCOMControls.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0A Size: 003AC  File:
apps/base/Space.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0A Size: 004CC  File:
apps/base/UP4BApp.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 0A Size: 00110  File:
apps/base/WAPSetup.bqr
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 10 Size: 00B5C  File:
VoiceDB/Lang/fr/fcadat_sd1.dtw
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 10 Size: 0B1FC  File:
VoiceDB/Lang/fr/fcadat_sd1.prm
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 10 Size: 00B5C  File:
VoiceDB/Lang/es/spadat_sd1.dtw
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 10 Size: 0EABC  File:
VoiceDB/Lang/es/spadat_sd1.prm
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 10 Size: 04F24  File:
VoiceDB/Lang/en/engdat1.dtw
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 10 Size: 057BA  File:
VoiceDB/Lang/en/engdat1.hmm
Unknown1: 01 1F 00 00 00 Unknown2: 00 00 00 00 10 Size: 0EAF4  File:
VoiceDB/Lang/en/engdat1.prm
Unknown1: 01 FF 00 01 00 Unknown2: 00 66 00 00 15 Size: 06280  File:
VoiceDB/All/Patterns/NameTag.int
Unknown1: 01 FF 00 01 00 Unknown2: 00 16 00 00 15 Size: 014BC  File:
VoiceDB/All/Patterns/CtrlWrd.int
Unknown1: 01 FF 00 01 00 Unknown2: 00 02 00 00 12 Size: 00004  File:
VoiceDB/All/Memos/NextMemo.int
Unknown1: 01 FF 00 00 00 Unknown2: 00 0A 00 00 12 Size: 0087E  File:
VoiceDB/All/Memos/Mem00017.qcp
Unknown1: 01 FF 00 00 00 Unknown2: 00 08 00 00 12 Size: 00614  File:
VoiceDB/All/Memos/Mem00018.qcp
Unknown1: 01 FF 00 00 00 Unknown2: 00 0C 00 00 12 Size: 00A84  File:
VoiceDB/All/Memos/Mem00021.qcp
Unknown1: 01 FF 00 00 00 Unknown2: 00 12 00 00 12 Size: 0101C  File:
VoiceDB/All/Memos/Mem00022.qcp
Unknown1: 01 FF 00 00 00 Unknown2: 00 2E 00 00 12 Size: 02ADC  File:
VoiceDB/All/Memos/Mem00023.qcp
Unknown1: 01 FF 00 00 00 Unknown2: 00 CE 01 00 12 Size: 1BEDE  File:
VoiceDB/All/Memos/Mem00025.qcp
----------------------------------------------------------------------------
--------------------------

My deduction is that the unknown2 field 5th byte is the length of the
pathname string and the next byte is the length of the filename string.

Additionally, I'm guessing that the first byte of "unknown1" is a flag for
01 meaning an "extended" field of 5 bytes, with the next dword being a set
of flags (1F=system, 37=read only, FF=all, ???). What is also interesting is
that files with the Unknown byte "1F" above are all in "ROM" and don't take
up EFS space, and therefore the Unknown2 dword field is all zeroes.

So my next guess is that the first dword of Unknown2 is the EFS file space
taken up by the file (which implies even boundaries of 256 bytes and
therefore the first byte of '00'). It also looks like there is a minimum of
"200h" bytes for a file which is the minimum for a block size of up to 100h
bytes plus the additional header info.

Hope this helps, Thanks!
-- Steve Marchant

-----Original Message-----
From: bit...@li...
[mailto:bit...@li...]On Behalf Of Roger
Binns
Sent: Sunday, March 14, 2004 10:23 PM
To: bit...@li...
Subject: Re: [Bitpim-devel] Support for Kyocera 7135 (QC MSM5100)


> VX6000    FF 00 01 00
> CDM8900   FF 00 01 03  (last 03 is sometimes zero)
> VX4400    FF 00 01 00

> VX4500    FF 00 00 00
> VX4500    FF 00 01 01
> VX4500    FF 00 01 03

> SCP5500   FF 00 01 03
> SCP5500   37 00 01 03

I also had the CDM8900 have 37 as first byte of unknown1
after looking in several other directories.

So it doesn't look like unknown1 can be used as a useful predictor
of the extra byte for the Kyocera 7135 (incidentally Kyocera typically
just rebadge Qualcomm phones and hence are closest to the "real thing").

The second byte of unknown2 seems to be somewhat related to file
size.  (The protocol uses a block size of 256 bytes).

Hopefully Stephgen Marchant can figure out some form of indicator
since I really don't want to have variations on the brew protocol.
(I will do so if there is no choice).

Roger


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Bitpim-devel mailing list
Bit...@li...
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

Re: [Bitpim-devel] bitpim 0.7test6 build

[Roger B. <ro...@ro...>]

> Stephen,

That should of course be Steven.  Apologies for getting it wrong.

> Have you managed to do the build yet?

I now have the files and am doing the build.

Roger