Hello to everybody,
I'm quite new here, so please bear my ignorance. The question is if I
can
run Dynamic C from Linux environment. The Rabbit board is connected with a
serial line. I understand there's no Linux version so I tried running it
from VMware box. To no avail, unfortunately (No Rabbit Processor
Detected). The next step was to try the WINE emulator, which didn't work
neither. WINE is an open source project so I've managed to find a bug
there and fixed it (for those interested - the SetCommState function does
not honor DTR bit settings which is used [as described in z2k project] to
reset the target). Unfortunately this seems not to be the only problem (as
Dynamic C still fails to detect the Rabbit). Anyone has an idea what I
can do with it?
An alternative solution would be to have a "RabbitLink emulator" which
could be run on my Linux Box (a small program acting as an interface
between "Dynamic C TCP/IP Communication" option and real Rabbit board
connected to the serial port). Assuming this thing is somewhat simple I
can code it myself (if this is not done yet) but I see no specifications
available.
I will really appreciate any help, without making it work together I can
not go any further. And I have a pretty urgent project to be done with
this thing :-(
Thanks in advance
-L.
P.S. It works when booted in Windows. But the idea of setting all software
I use under Windows (if it exists) makes me sick. z2k is fine (leaving
alone that I am not familiar with Rabbit assembly) but I should add
features to an existing Dynamic C based project...
Dynamic C under VMware, WINE, or Linux RabbitLink available?
Started by ●February 1, 2004
Reply by ●February 1, 20042004-02-01
I've never done anything but windows for rabbit targets. Is it too
offensive to just use a windows box for the project? If you were planning on
using the DC environment anyhow, you couldn't really use a bunch of your
other software to debug the code. What other software would you need for this
project that you have to "set under windows"? You could just use the windows
box to compile and download code to the rabbit, then switch over to your other
box. If you were using the DC environment to debug, then you'd have to use
that OS independent environment anyhow. What am I missing here?
Reply by ●February 2, 20042004-02-02
I use what I need to, to make $ regardless of how I feel about it.
If I had a paying job that needed me to run linux, OS/2 etc...
guess what I'd be running?
If you cant get it running under vmware there is probably not much
hope of it working. Vmware IMO is the best choice for doing
what you are trying. I'm guessing here but there is probably alot
of leftover code that is VERY dated in Dynamic C that is preventing
it from running under vmware.
my $0.02
If I had a paying job that needed me to run linux, OS/2 etc...
guess what I'd be running?
If you cant get it running under vmware there is probably not much
hope of it working. Vmware IMO is the best choice for doing
what you are trying. I'm guessing here but there is probably alot
of leftover code that is VERY dated in Dynamic C that is preventing
it from running under vmware.
my $0.02
Reply by ●February 2, 20042004-02-02
Matt Linder wrote:
> If you cant get it running under vmware there is probably not much
> hope of it working. Vmware IMO is the best choice for doing
> what you are trying. I'm guessing here but there is probably alot
> of leftover code that is VERY dated in Dynamic C that is preventing
> it from running under vmware.
It's been a few years since I looked at running Dynamic C under WINE,
but as I recall the problem was Windows serial functions that were not
yet supposed under WINE, not the dated code in Dynamic C :v)
In particular, Dynamic C uses the DTR line to reset the board and checks
for the existence of a processor by telling the processor to enable the
STATUS line, which is connected to the DSR line. Back when I looked into
it, the problem was that WINE didn't support the Windows calls Dynamic C
used to trigger those events.
Take a look at the "Rabbit 3000 Microprocessor Designer's Handbook" for
a detailed description of how the coldboot/load sequence goes. There is
also a schematic of the programming cable -- look for both of them at
www.rabbitsemiconductor.com.
-Lynn
> If you cant get it running under vmware there is probably not much
> hope of it working. Vmware IMO is the best choice for doing
> what you are trying. I'm guessing here but there is probably alot
> of leftover code that is VERY dated in Dynamic C that is preventing
> it from running under vmware.
It's been a few years since I looked at running Dynamic C under WINE,
but as I recall the problem was Windows serial functions that were not
yet supposed under WINE, not the dated code in Dynamic C :v)
In particular, Dynamic C uses the DTR line to reset the board and checks
for the existence of a processor by telling the processor to enable the
STATUS line, which is connected to the DSR line. Back when I looked into
it, the problem was that WINE didn't support the Windows calls Dynamic C
used to trigger those events.
Take a look at the "Rabbit 3000 Microprocessor Designer's Handbook" for
a detailed description of how the coldboot/load sequence goes. There is
also a schematic of the programming cable -- look for both of them at
www.rabbitsemiconductor.com.
-Lynn
Reply by ●February 3, 20042004-02-03
Hi again, thanks for the comments.
On Mon, 2 Feb 2004 at 8:42am, Lynn S. Wood wrote:
> It's been a few years since I looked at running Dynamic C under WINE,
> but as I recall the problem was Windows serial functions that were not
> yet supposed under WINE, not the dated code in Dynamic C :v)
Exactly what I mentioned in the original message. The SetCommState
function does not set DTR line. I have fixed it but the problem is not
gone. So I assume there's another bug in WINE which prevents Dynamic C
from running :-(. Taking into account your email address, may I ask you to
assist me with the problem? I'd be glad to make Dynamic C and WINE work
together (having some experience with Linux AND Windows) and it looks like
ZWorld would also benefit if they do. Originally I used 7.05TSE and
yesterday upgraded to 7.21TSE. The latter has an additional "Enable DSR
verification" option but this makes no difference. Well, there's a
difference - 7.21 clears DTR, than sets, and then clears again. While
7.05 omits the first clear DTR step...
> Take a look at the "Rabbit 3000 Microprocessor Designer's Handbook" for
Thanks. What I have is Rabbit 2000 so I have consulted appropriate
reference. It adds some understanding but I still have no idea how to
debug the problem. Help me, please...
On Sun, 1 Feb 2004 at 9:10am, Dave Moore wrote:
> other software to debug the code. What other software would you need
> for this project that you have to "set under windows"? You could just
> use the windows box to compile and download code to the rabbit, then
Well, not the question I like very much to think about, but... if you ask.
First I will have to install Windows itself. With all stuff about
hardware. I don't say if it is easier to do under Linux or Windows. The
statement is that I do have everything set up already the way I like it
and don't want to spend time doing it again. I would rather spend time to
make WINE work properly so that others wouldn't have the same problem. And
I need email client, and browser and instant messenger and... This is what
I like about working at home - there's no need to drive an hour to the
workplace and back, no need to transfer files, addressbooks, mailfolders
between computers, no need for all this schizophrenia.
On Mon, 2 Feb 2004 at 10:03am, Matt Linder wrote:
> I use what I need to, to make $ regardless of how I feel about it. If I
> had a paying job that needed me to run linux, OS/2 etc... guess what I'd
Please understand my point, I don't mean to start any religious war here.
There's nothing about feelings or so. It is just about convenience. And,
this is not the first embedded project I have and I have managed to run
other (serial-attached) source-line debugger from Linux (within VMware).
Why not Rabbit?
-L.
On Mon, 2 Feb 2004 at 8:42am, Lynn S. Wood wrote:
> It's been a few years since I looked at running Dynamic C under WINE,
> but as I recall the problem was Windows serial functions that were not
> yet supposed under WINE, not the dated code in Dynamic C :v)
Exactly what I mentioned in the original message. The SetCommState
function does not set DTR line. I have fixed it but the problem is not
gone. So I assume there's another bug in WINE which prevents Dynamic C
from running :-(. Taking into account your email address, may I ask you to
assist me with the problem? I'd be glad to make Dynamic C and WINE work
together (having some experience with Linux AND Windows) and it looks like
ZWorld would also benefit if they do. Originally I used 7.05TSE and
yesterday upgraded to 7.21TSE. The latter has an additional "Enable DSR
verification" option but this makes no difference. Well, there's a
difference - 7.21 clears DTR, than sets, and then clears again. While
7.05 omits the first clear DTR step...
> Take a look at the "Rabbit 3000 Microprocessor Designer's Handbook" for
Thanks. What I have is Rabbit 2000 so I have consulted appropriate
reference. It adds some understanding but I still have no idea how to
debug the problem. Help me, please...
On Sun, 1 Feb 2004 at 9:10am, Dave Moore wrote:
> other software to debug the code. What other software would you need
> for this project that you have to "set under windows"? You could just
> use the windows box to compile and download code to the rabbit, then
Well, not the question I like very much to think about, but... if you ask.
First I will have to install Windows itself. With all stuff about
hardware. I don't say if it is easier to do under Linux or Windows. The
statement is that I do have everything set up already the way I like it
and don't want to spend time doing it again. I would rather spend time to
make WINE work properly so that others wouldn't have the same problem. And
I need email client, and browser and instant messenger and... This is what
I like about working at home - there's no need to drive an hour to the
workplace and back, no need to transfer files, addressbooks, mailfolders
between computers, no need for all this schizophrenia.
On Mon, 2 Feb 2004 at 10:03am, Matt Linder wrote:
> I use what I need to, to make $ regardless of how I feel about it. If I
> had a paying job that needed me to run linux, OS/2 etc... guess what I'd
Please understand my point, I don't mean to start any religious war here.
There's nothing about feelings or so. It is just about convenience. And,
this is not the first embedded project I have and I have managed to run
other (serial-attached) source-line debugger from Linux (within VMware).
Why not Rabbit?
-L.
Reply by ●February 3, 20042004-02-03
Lev A. Melnikovsky wrote:
> > It's been a few years since I looked at running Dynamic C under WINE,
> > but as I recall the problem was Windows serial functions that were not
> > yet supposed under WINE, not the dated code in Dynamic C :v)
> Exactly what I mentioned in the original message. The SetCommState
> function does not set DTR line. I have fixed it but the problem is not
> gone. So I assume there's another bug in WINE which prevents Dynamic C
> from running :-(.
Well, the serial problems were just the FIRST bug I saw, so yes there
may be more. Odds are they are all serial related, however... watching
the serial lines to see what is being communicated (or not) may tell
you more.
> Taking into account your email address, may I ask you to
> assist me with the problem? I'd be glad to make Dynamic C and WINE work
> together (having some experience with Linux AND Windows) and it looks like
> ZWorld would also benefit if they do. Originally I used 7.05TSE and
> yesterday upgraded to 7.21TSE. The latter has an additional "Enable DSR
> verification" option but this makes no difference. Well, there's a
> difference - 7.21 clears DTR, than sets, and then clears again. While
> 7.05 omits the first clear DTR step...
Well, I can help a little bit (i.e. write some emails to this group :v), but
I'm not even in the software group any more (like I was when I first looked
at DynC under WINE), so I can't really spend any actual time working on it :v)
DTR is connected to the RESET line of the processor. When DynC sets/clears
DTR, it is resetting the processor. The "Enable DSR verification" option
is used to detect the presence of a processor: DSR is connected to the STATUS
line of the processor. After reset, the processor is told to enable the
STATUS line and DynC looks for that change. Unchecking the verification
option skips that check -- you shouldn't be seeing the "Processor not
detected" error if that is disabled.
The exact sequence of messages that DynC reports helps determine where the
process is halting, i.e. "Detecting processor", "Downloaded PILOT BIOS", etc.
(I don't recall what the messages are exactly in 7.21 -- that was a long
time ago :v)
Versions 8.0 and later of DynC are significantly updated from the 7.0 series.
Using one of those may be more successful under WINE/VMWare/etc. -- has anyone
tried?
-Lynn
> > It's been a few years since I looked at running Dynamic C under WINE,
> > but as I recall the problem was Windows serial functions that were not
> > yet supposed under WINE, not the dated code in Dynamic C :v)
> Exactly what I mentioned in the original message. The SetCommState
> function does not set DTR line. I have fixed it but the problem is not
> gone. So I assume there's another bug in WINE which prevents Dynamic C
> from running :-(.
Well, the serial problems were just the FIRST bug I saw, so yes there
may be more. Odds are they are all serial related, however... watching
the serial lines to see what is being communicated (or not) may tell
you more.
> Taking into account your email address, may I ask you to
> assist me with the problem? I'd be glad to make Dynamic C and WINE work
> together (having some experience with Linux AND Windows) and it looks like
> ZWorld would also benefit if they do. Originally I used 7.05TSE and
> yesterday upgraded to 7.21TSE. The latter has an additional "Enable DSR
> verification" option but this makes no difference. Well, there's a
> difference - 7.21 clears DTR, than sets, and then clears again. While
> 7.05 omits the first clear DTR step...
Well, I can help a little bit (i.e. write some emails to this group :v), but
I'm not even in the software group any more (like I was when I first looked
at DynC under WINE), so I can't really spend any actual time working on it :v)
DTR is connected to the RESET line of the processor. When DynC sets/clears
DTR, it is resetting the processor. The "Enable DSR verification" option
is used to detect the presence of a processor: DSR is connected to the STATUS
line of the processor. After reset, the processor is told to enable the
STATUS line and DynC looks for that change. Unchecking the verification
option skips that check -- you shouldn't be seeing the "Processor not
detected" error if that is disabled.
The exact sequence of messages that DynC reports helps determine where the
process is halting, i.e. "Detecting processor", "Downloaded PILOT BIOS", etc.
(I don't recall what the messages are exactly in 7.21 -- that was a long
time ago :v)
Versions 8.0 and later of DynC are significantly updated from the 7.0 series.
Using one of those may be more successful under WINE/VMWare/etc. -- has anyone
tried?
-Lynn
Reply by ●February 3, 20042004-02-03
On Tue, 3 Feb 2004 at 9:39am, Lynn S. Wood wrote:
> Odds are they are all serial related, however... watching the serial
> lines to see what is being communicated (or not) may tell you more.
I have verified with a null-modem cable that the DTR line is pulsed during
startup (if I patch WINE). The strange thing is that the RTS line is also
pulsed (no idea why) but this is as instructed by Dynamic C.
> Well, I can help a little bit (i.e. write some emails to this group :v),
> but I'm not even in the software group any more (like I was when I first
> looked at DynC under WINE), so I can't really spend any actual time
Perhaps you know someone interested in resolving this issue? It'd be nice
if he contacts me directly. I smell it, it should be something very
stupid/simple. Pity if not done...
> The exact sequence of messages that DynC reports helps determine where the
> process is halting, i.e. "Detecting processor", "Downloaded PILOT BIOS", etc.
It stops with "While Sending Cold Loader: No Rabbit Processor Detected."
or (if DSR verification is disabled) with "While Sending Pilot BIOS:
Target communication error." It samples DSR line two times after DTR pulse
and it is high both times and I understand this is not the way it should
be. Any idea what can prevent the target from being reset? from proper
response?
> Versions 8.0 and later of DynC are significantly updated from the 7.0 series.
Well, if you tell me it works I'll make my employer buy it. Do you?
> Using one of those may be more successful under WINE/VMWare/etc. -- has anyone
> tried?
Anyway no version would work under current WINE as it does not set DTR
properly.
-L.
> Odds are they are all serial related, however... watching the serial
> lines to see what is being communicated (or not) may tell you more.
I have verified with a null-modem cable that the DTR line is pulsed during
startup (if I patch WINE). The strange thing is that the RTS line is also
pulsed (no idea why) but this is as instructed by Dynamic C.
> Well, I can help a little bit (i.e. write some emails to this group :v),
> but I'm not even in the software group any more (like I was when I first
> looked at DynC under WINE), so I can't really spend any actual time
Perhaps you know someone interested in resolving this issue? It'd be nice
if he contacts me directly. I smell it, it should be something very
stupid/simple. Pity if not done...
> The exact sequence of messages that DynC reports helps determine where the
> process is halting, i.e. "Detecting processor", "Downloaded PILOT BIOS", etc.
It stops with "While Sending Cold Loader: No Rabbit Processor Detected."
or (if DSR verification is disabled) with "While Sending Pilot BIOS:
Target communication error." It samples DSR line two times after DTR pulse
and it is high both times and I understand this is not the way it should
be. Any idea what can prevent the target from being reset? from proper
response?
> Versions 8.0 and later of DynC are significantly updated from the 7.0 series.
Well, if you tell me it works I'll make my employer buy it. Do you?
> Using one of those may be more successful under WINE/VMWare/etc. -- has anyone
> tried?
Anyway no version would work under current WINE as it does not set DTR
properly.
-L.
Reply by ●February 3, 20042004-02-03
Lev A. Melnikovsky wrote:
> I have verified with a null-modem cable that the DTR line is pulsed during
> startup (if I patch WINE). The strange thing is that the RTS line is also
> pulsed (no idea why) but this is as instructed by Dynamic C.
RTS is connected to CTS on the programming cable (see the schematic), so
you're just seeing your computer set the lines.
> It stops with "While Sending Cold Loader: No Rabbit Processor Detected."
> or (if DSR verification is disabled) with "While Sending Pilot BIOS:
> Target communication error." It samples DSR line two times after DTR pulse
> and it is high both times and I understand this is not the way it should
> be. Any idea what can prevent the target from being reset? from proper
> response?
Make sure that the DTR pulse is actually making it to the processor -- the
RESET signal should drop low for 0.5 sec when DTR is asserted. Depending
on the device you're programming, that signal may or may not be easily
available :v)
The "no rabbit processor detected" means that either (a) the signal to
assert the STATUS line didn't make it to the processor, or (b) the STATUS
signal isn't making it back via the DSR line.
If the reset is making it to the device, then (assuming you disabled the
processor verification) you should next see some 2400 baud data going to
the processor (telling it to assert the STATUS line and loading the
coldloader), then 57600 baud data going both to and from the processor
(loading the pilot BIOS).
> > Versions 8.0 and later of DynC are significantly updated from the 7.0
> series.
> Well, if you tell me it works I'll make my employer buy it. Do you?
I have no idea, but a lot of the communications code was rewritten in
a more recent compiler than the 7.0 series, so it's possible that some
WINE bugs may no longer be hit :v)
BTW, have you submitted the WINE bugfix yet? Please send the changes to
me as well when you get a chance (although I still don't have any time to
work on it :v)
Thanks,
-Lynn
> I have verified with a null-modem cable that the DTR line is pulsed during
> startup (if I patch WINE). The strange thing is that the RTS line is also
> pulsed (no idea why) but this is as instructed by Dynamic C.
RTS is connected to CTS on the programming cable (see the schematic), so
you're just seeing your computer set the lines.
> It stops with "While Sending Cold Loader: No Rabbit Processor Detected."
> or (if DSR verification is disabled) with "While Sending Pilot BIOS:
> Target communication error." It samples DSR line two times after DTR pulse
> and it is high both times and I understand this is not the way it should
> be. Any idea what can prevent the target from being reset? from proper
> response?
Make sure that the DTR pulse is actually making it to the processor -- the
RESET signal should drop low for 0.5 sec when DTR is asserted. Depending
on the device you're programming, that signal may or may not be easily
available :v)
The "no rabbit processor detected" means that either (a) the signal to
assert the STATUS line didn't make it to the processor, or (b) the STATUS
signal isn't making it back via the DSR line.
If the reset is making it to the device, then (assuming you disabled the
processor verification) you should next see some 2400 baud data going to
the processor (telling it to assert the STATUS line and loading the
coldloader), then 57600 baud data going both to and from the processor
(loading the pilot BIOS).
> > Versions 8.0 and later of DynC are significantly updated from the 7.0
> series.
> Well, if you tell me it works I'll make my employer buy it. Do you?
I have no idea, but a lot of the communications code was rewritten in
a more recent compiler than the 7.0 series, so it's possible that some
WINE bugs may no longer be hit :v)
BTW, have you submitted the WINE bugfix yet? Please send the changes to
me as well when you get a chance (although I still don't have any time to
work on it :v)
Thanks,
-Lynn
Reply by ●February 5, 20042004-02-05
Hello,
It's hard to believe that nobody have a chance to test DynC 8 under VMware
:-( Please!!! I would greatly appreciate some result. Positive or
negative.
On Tue, 3 Feb 2004 at 3:06pm, Lynn S. Wood wrote:
> > I have verified with a null-modem cable that the DTR line is pulsed during
> > startup (if I patch WINE). The strange thing is that the RTS line is also
> > pulsed (no idea why) but this is as instructed by Dynamic C.
> RTS is connected to CTS on the programming cable (see the schematic), so
> you're just seeing your computer set the lines.
Sorry, perhaps I was not clear enough. I've disconnected the Rabbit board
and simply attached two PC serial ports with a null-modem to observe
status lines. And the trace shows three requests in the very beginning:
#1. RTS=0 DTR=0
#2. RTS=1 DTR=1
#3. RTS=1 DTR=0
Whatever it means...
> Make sure that the DTR pulse is actually making it to the processor --
> the RESET signal should drop low for 0.5 sec when DTR is asserted.
> Depending on the device you're programming, that signal may or may not
> be easily available :v)
Well, I must admit that you've managed to frighten me a bit :-)
I am trying to stay in the software-debugging domain. So the state of the
target after pulsing DTR is characterized by very short pulses of DSR line
(about two times a second DSR drops from 1 to 0 and, after a very short
while, returns to 1). Is this an after-reset-state?
> The "no rabbit processor detected" means that either (a) the signal to
> assert the STATUS line didn't make it to the processor, or
Didn't you mean /RESET here?
> (b) the STATUS signal isn't making it back via the DSR line.
It looks like it is. I mean who is pulling the DSR otherwise?
> If the reset is making it to the device, then (assuming you disabled the
> processor verification) you should next see some 2400 baud data going to
> the processor (telling it to assert the STATUS line and loading the
Hmm. Even when I enable DSR verification what I see is the following:
#4. Send 3 or 4 (not sure) bytes
#5. Sample DSR (it is 1)
#6. Send MANY (~500) bytes
#7. Sample DSR (it is again 1)
This is the point where it kicks out with "No Rabbit"...
Is this a proper sequence? Do you suspect some multi threading issue?
> I have no idea, but a lot of the communications code was rewritten in a
This is where I hope to get some help from the community. I hope someone
would have DynC 8 and VMware licenses simultaneously...
> BTW, have you submitted the WINE bugfix yet? Please send the changes to
No, not yet. I (still) hope to make the Rabbit work. Otherwise this is a
bugfix but not a FIX...
Yours
-L.
It's hard to believe that nobody have a chance to test DynC 8 under VMware
:-( Please!!! I would greatly appreciate some result. Positive or
negative.
On Tue, 3 Feb 2004 at 3:06pm, Lynn S. Wood wrote:
> > I have verified with a null-modem cable that the DTR line is pulsed during
> > startup (if I patch WINE). The strange thing is that the RTS line is also
> > pulsed (no idea why) but this is as instructed by Dynamic C.
> RTS is connected to CTS on the programming cable (see the schematic), so
> you're just seeing your computer set the lines.
Sorry, perhaps I was not clear enough. I've disconnected the Rabbit board
and simply attached two PC serial ports with a null-modem to observe
status lines. And the trace shows three requests in the very beginning:
#1. RTS=0 DTR=0
#2. RTS=1 DTR=1
#3. RTS=1 DTR=0
Whatever it means...
> Make sure that the DTR pulse is actually making it to the processor --
> the RESET signal should drop low for 0.5 sec when DTR is asserted.
> Depending on the device you're programming, that signal may or may not
> be easily available :v)
Well, I must admit that you've managed to frighten me a bit :-)
I am trying to stay in the software-debugging domain. So the state of the
target after pulsing DTR is characterized by very short pulses of DSR line
(about two times a second DSR drops from 1 to 0 and, after a very short
while, returns to 1). Is this an after-reset-state?
> The "no rabbit processor detected" means that either (a) the signal to
> assert the STATUS line didn't make it to the processor, or
Didn't you mean /RESET here?
> (b) the STATUS signal isn't making it back via the DSR line.
It looks like it is. I mean who is pulling the DSR otherwise?
> If the reset is making it to the device, then (assuming you disabled the
> processor verification) you should next see some 2400 baud data going to
> the processor (telling it to assert the STATUS line and loading the
Hmm. Even when I enable DSR verification what I see is the following:
#4. Send 3 or 4 (not sure) bytes
#5. Sample DSR (it is 1)
#6. Send MANY (~500) bytes
#7. Sample DSR (it is again 1)
This is the point where it kicks out with "No Rabbit"...
Is this a proper sequence? Do you suspect some multi threading issue?
> I have no idea, but a lot of the communications code was rewritten in a
This is where I hope to get some help from the community. I hope someone
would have DynC 8 and VMware licenses simultaneously...
> BTW, have you submitted the WINE bugfix yet? Please send the changes to
No, not yet. I (still) hope to make the Rabbit work. Otherwise this is a
bugfix but not a FIX...
Yours
-L.
Reply by ●February 11, 20042004-02-11
El jue, 05-02-2004 a las 07:45, Lev A. Melnikovsky escribi
> Hello,
>
> It's hard to believe that nobody have a chance to test DynC 8 under VMware
> :-( Please!!! I would greatly appreciate some result. Positive or
> negative.
>
Lev:
Don't waste your time.
Dynamic C just don't work in WINE/VMWARE.
Other apps using serials works fine, but Dyncamic C just don't.
If you search in the newsgroups you will see many complaints from me
about that incredible trouble.
The reality is , Zworld don't care that. And the reallity is only they,
recoding Dynamic C to Linux can solve that.
Dynamic C is developed in Borland C, so why they don't release a Kylix
Version (fifty days work?) is one of the greater misterious on the word.
I offer to migrate interfaces and off course they slaught to me.
Anyway, you are FORCE by Zworld to use Windows...
Open your mind, Zworld.
--
German Pablo Gentile
Dpto. de Desarrollo y Tecnolog.
Cyberia IT
www.cyberiait.com.ar
Ciudad Autonoma de Buenos Aires
Argentina
> Hello,
>
> It's hard to believe that nobody have a chance to test DynC 8 under VMware
> :-( Please!!! I would greatly appreciate some result. Positive or
> negative.
>
Lev:
Don't waste your time.
Dynamic C just don't work in WINE/VMWARE.
Other apps using serials works fine, but Dyncamic C just don't.
If you search in the newsgroups you will see many complaints from me
about that incredible trouble.
The reality is , Zworld don't care that. And the reallity is only they,
recoding Dynamic C to Linux can solve that.
Dynamic C is developed in Borland C, so why they don't release a Kylix
Version (fifty days work?) is one of the greater misterious on the word.
I offer to migrate interfaces and off course they slaught to me.
Anyway, you are FORCE by Zworld to use Windows...
Open your mind, Zworld.
--
German Pablo Gentile
Dpto. de Desarrollo y Tecnolog.
Cyberia IT
www.cyberiait.com.ar
Ciudad Autonoma de Buenos Aires
Argentina
