NO

Author Topic: Acclimation Help  (Read 23620 times)

Offline Bitbeisser

  • Global Moderator
  • Member
  • *****
  • Posts: 772
Re: Acclimation Help
« Reply #15 on: September 24, 2011, 04:50:10 AM »
As a rule it's better to build lib based programs...

Project -> Options -> Compiler -> Runttime Library...

Either "Single-threaded (LIB)" or "Multi-threaded (LIB)" depending if you are using mutliple threads or not...

The advantage is that you don't have to distribute pocrt*.dll with your programs. 
They free stand and run without external support.
Well, the advantage of a DLL in return is that you can change the logic and coding within and update the DLL on all distributed systems without having to replace\update the whole program. As long as exported symbols and parameters of course stay the same...

Ralf

CommonTater

  • Guest
Re: Acclimation Help
« Reply #16 on: September 24, 2011, 05:23:26 AM »
(Grin) and in turn... it's just as easy to replace the program as the DLL... And then if changes to the DLL require changes to the program... you end up replacing both.

(Your turn)


Offline Bitbeisser

  • Global Moderator
  • Member
  • *****
  • Posts: 772
Re: Acclimation Help
« Reply #17 on: September 24, 2011, 11:52:46 PM »
(Grin) and in turn... it's just as easy to replace the program as the DLL... And then if changes to the DLL require changes to the program... you end up replacing both.

(Your turn)
Well, the former is not necessarily true. I have one application (not written in (Pelle's) C though, but that doesn't matter) where I can include a database related DLL depending on the database engine to be used.

For example, for a single user, I include one which internal works with a Sqlite database. If that user upgrades to a multi-user MySQL MariaDB setup, I just need to replace that specific DLL and it turns the application into a multi-user one. Or if someone moves from a dedicated MySQL database to a shared MS SQL Server or Oracle setup, it's again just a switch of the DLL and done.

Changes necessary to the interface of the DLL which would require a change in the program itself can easily be avoided by planning a bit ahead. Programming doesn't mean  just hacking along at the source code...  8)

Ralf

CommonTater

  • Guest
Re: Acclimation Help
« Reply #18 on: September 25, 2011, 01:21:36 AM »
LOL... I don't necessarily disagree with you... and you're preaching to the choir about programming being more than just typing source...

But it still remains that one could just as easily replace a 1 piece program as that DLL file...

Having written several addins and libraries for Pelles C... yes I do see the value in replaceable libraries... but on the question of which is easier to replace, I think it's a tie.

Offline Bitbeisser

  • Global Moderator
  • Member
  • *****
  • Posts: 772
Re: Acclimation Help
« Reply #19 on: September 25, 2011, 07:08:56 AM »
LOL... I don't necessarily disagree with you... and you're preaching to the choir about programming being more than just typing source...
I was very tempted the other day to post a reply to that dude that complained that Pelle's C is compiling so slow... ;-)
Quote
But it still remains that one could just as easily replace a 1 piece program as that DLL file...

Having written several addins and libraries for Pelles C... yes I do see the value in replaceable libraries... but on the question of which is easier to replace, I think it's a tie.
That certainly depends on the size/complexity of your projects... ;-)

And DLLs are easily usable across projects as well.

Ralf

CommonTater

  • Guest
Re: Acclimation Help
« Reply #20 on: September 25, 2011, 08:35:18 AM »
Yep, it sure does hinge on both size and complexity.

I was talking strictly about the mechanics of replacing a file... it's as easy to drag and drop an executable as a DLL... Last time I looked they both weigh about the same.

Believe me...  I get the whole DLL thing just fine and have used them in several of my projects.

Going back to my point to the OP... rather than distributing POCRT with my projects I prefer to link statically... Your point about it being replaceable is totally valid... but whenever possible I like keeping things nice and simple... One file, job done...   


mathguy

  • Guest
Re: Acclimation Help
« Reply #21 on: September 26, 2011, 06:31:13 PM »
Okay...I think only one more question and I hope to have this wrapped up.  In most IDEs, there is an option for Data Structure Alignment (/Zp#).  I do not find that in Pelles C.  Is it not there?  Or, am I just missing it?  If it isn't there, can I just modify the command line in the Compiler options window and add the /Zp# to it?

Thanks again, guys!

CommonTater

  • Guest
Re: Acclimation Help
« Reply #22 on: September 26, 2011, 09:59:06 PM »
Look in your help files for the Command Line Tools -> POCC -> Command Line Options... if it ain't there, you can't use it.

Also look at the list of compiler pragmas... While it is mostly recommended that you leave the default alignment (4 on x86 or 8 for amd64) alone, on those rare occasions where raw data has to be transmitted from one machine to another you can use the #pragma pack(??) preprocessor to affect only what's needed.

Code: [Select]
#pragma pack (1)
typedef struct t_sendme
  { char name[100];
     int values[43]; }
   sendme, *psendme;
#pragma pack ()

I should warn you that I ran full blown bug on windshield into this issue some time back and you will find a couple of threads here where I struggled royally as the others did their best to help me out...  Basically what I took from that rather sobering experience is that you just don't mess with stuff you don't need to mess with.



« Last Edit: September 26, 2011, 10:01:50 PM by CommonTater »

mathguy

  • Guest
Re: Acclimation Help
« Reply #23 on: September 26, 2011, 10:54:22 PM »
Well, it doesn't look like it's there.  That sucks.  And, I don't think that it is actually using 4-byte for x86.  I am trying to call this DLL from a Visual Basic program.  For that reason, the data structure that we use needs to be on a 4-byte alignment.  When I use the pragma pack statement, we can call the DLL but get some gibberish midway through the data structure.  This usually means that the alignment is not quite as expected.  If we don't use the pragma statement, we get a stuck DLL (i.e. infinite loop) which means a dramatic alignment issue.  My guess is that the pragma is working but maybe something else in this build isn't what it seems.  I will dig.  The frustrating thing is that a Borland 4.5 build of this same code works fine.  Oh well, back to head scratching and sleuthing!  Thanks, as always!

CommonTater

  • Guest
Re: Acclimation Help
« Reply #24 on: September 27, 2011, 12:06:13 AM »
Most likely it's the padding that's causing you the problem...  When you align on 4 byte boundaries the compiler has to insert extra bytes to make the struct a multiple of 4 bytes in size... Now WHERE it inserts those 4 bytes is something we won't necessarily know... we can make some educated guesses such as padding a string to align an int behind it, but we won't always know exactly where the extra bytes are inserted.

So along comes Visual Basic (another language that should never have reached the market) it expects padding at location x but Pelles C has used location y ... now the starting points for each variable in the rest of the struct are wrong, hense, garbage results.

Are you compiling your DLL as 32 bits or 64 bits...  Windows has rules about this... a 32 bit program *cannot* load a 64bit DLL... a 64bit program *cannot* load a 32bit DLL ... this because of the differences in pointers addresses and, yes, alignment.

http://msdn.microsoft.com/en-us/library/aa384198(v=vs.85).aspx

« Last Edit: September 27, 2011, 12:08:33 AM by CommonTater »

Offline TimoVJL

  • Global Moderator
  • Member
  • *****
  • Posts: 2115
Re: Acclimation Help
« Reply #25 on: September 27, 2011, 09:51:05 AM »
Is it possible to test those structures between compilers with some code like this ?
Code: [Select]
#include <stddef.h>
#include <stdio.h>

struct foo {
char a;
short b;
long c;
int d;
};

int main(void)
{
int a, b, c, d;
a = offsetof(struct foo, a);
b = offsetof(struct foo, b);
c = offsetof(struct foo, c);
d = offsetof(struct foo, d);
printf("%d\n%d %d %d %d\n", sizeof(struct foo), a, b, c, d);
return 0;
}
May the source be with you

mathguy

  • Guest
Re: Acclimation Help
« Reply #26 on: September 27, 2011, 04:26:42 PM »
Okay.  I've actually got it all working!  The pragma statement works and that's probably what I'm going with.  However, I also think I can add the command line argument in the options.  I'm looking at that now.

One thing that I forgot about Borland that was nice was that their resource compiler had a version number capability.  Does the Pelles IDE offer this?  I want to be able to tag the DLL with a version number that can be accessed by the Properties.

Guys, again, thank you so much for your help.  I really appreciate it!

Tater,

Right?  VB is a mess.  Unfortunately, we were stuck with it at an early time by a less-than-skilled "programmer".  We need to work toward a phase-out of it.

mathguy

  • Guest
Re: Acclimation Help
« Reply #27 on: September 27, 2011, 08:39:02 PM »
I figured out the Resource script to do versioning so my question has been answered.  Sorry to gobble up board space on it.

CommonTater

  • Guest
Re: Acclimation Help
« Reply #28 on: September 27, 2011, 10:49:27 PM »
This is just in case you did it the hard way...

You do know that Pelles C has a full suite of built in resource editors?  Rather than using manual scripts...

Click... File -> New -> Resources ... this will produce a new page in the editor with "untitled" at the top left...
Right click -> New -> Version ... this will open the version editor.  (Note there are several other useful editors there as well)

When done save the resource page, give it a name and click Yes when it asks if you want to add it.

Offline TimoVJL

  • Global Moderator
  • Member
  • *****
  • Posts: 2115
Re: Acclimation Help
« Reply #29 on: September 28, 2011, 07:08:19 AM »
PellesC IDE have add-in Buildver.dll (Increment build-number) for updating build-number.
May the source be with you