Compiler features
Robert T. Hannis
I run a small business based out of Phoenix, AZ. We've grown to the point
where payroll is becoming too complicated to do manually any more, so I'm
looking at contracting a programmer to create a bespoke C/C++ payroll
application for us.
In order to save on licensing costs I'm planning to use either lcc or
gcc/Eclipse as a free alternative to Visual Studio. Can anyone confirm
whether these compilers support the following key technologies: Windows
API, Windows Forms, MFC, .NET and OLE.
Any other comments and suggestions would be appreciated.
Sincerely,
Robert T. Hannis
Keith Thompson
Questions about lcc can be directed to comp.compilers.lcc. You should
be clear whether you're asking about lcc or lcc-win; the latter is
derived from the former, and is quite different.
As for gcc, the technologies you mention aren't part of the compiler
itself; they're associated with the environment and/or libraries that
might be provided with it. I'm not sure where to suggest asking about
this.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Kaz Kylheku
> Dear Forum:
>
> I run a small business based out of Phoenix, AZ. We've grown to the point
> where payroll is becoming too complicated to do manually any more, so I'm
> looking at contracting a programmer to create a bespoke C/C++ payroll
> application for us.
>
> In order to save on licensing costs I'm planning to use either lcc or
> gcc/Eclipse as a free alternative to Visual Studio. Can anyone confirm
> whether these compilers support the following key technologies: Windows
> API, Windows Forms, MFC, .NET and OLE.
*rolleyes*
Can anyone be this loonie for real?
You must be trolling. I will not bite twice though, I promise you.
The money you save by using free development tools is peanuts compared to
paying someone to develop a from-scratch payroll application in C++.
And what licensing costs do you think there are in running code compiled by
Visual C++?
Why do you care what language the damn program is written in, as long as it
computes the payrolls properly?
Since you will be using the program, rather than writing it, why would you pay
someone to write it in an unproductive, systems programming language, in which
it will likely take ten times as long to code and debug?
Why would, say, a Python or Java payroll system somehow not be an adequate
replacement for what today you are doing manually?
jacob navia
Hi Robert
I am the author of the lcc-win compiler.
Lcc-win supports:
o Windows API
o Windows Forms is unsupported since that runs only in the .NET
environment using the C# language
o MFC is unsupported since that is C++
o .Net is unsupported
o OLE is supported
Look, for doing a payroll application designing the screens is
not a big deal. Much more important (and you do not even mention it)
is the support for a data base and ODBC...
lcc-win comes with native support of SQLITE, a small database program
that uses SQL as the programming language. You can use SQL in a variety
of different data bases.
Note that gcc/Eclipse has no support for .NET or MFC either, since MFC
is a proprietary library from Microsoft Corp.
jacob navia
> Since you will be using the program, rather than writing it, why would you pay
> someone to write it in an unproductive, systems programming language, in which
> it will likely take ten times as long to code and debug?
>
C is just as productive for writing this kinds of applications as any
other language. The crucial advantage of C is that an application that
uses directly the windows API can be ported unchanged from one system to
the next without any rewriting. What kind of language that was OK in
windows 3.1 is still running the same code today?
You bet: C.
The applications I wrote using C and the windows API in windows 95
are still running today in VISTA or similar environments with minimal
changes. If you build applications in C they will stand the test of
time.
> Why would, say, a Python or Java payroll system somehow not be an adequate
> replacement for what today you are doing manually?
Sure.
Remember OWL? and the thousands of programming environments of 1995?
How many are still running today?
MFC hasn't been updated in 10 years, and was abandoned until very
recently when at last a small update was released by Microsoft.
If you use C+ Windows API you aren't tied to anybody.
jacob
user923005
> Dear Forum:
>
> I run a small business based out of Phoenix, AZ. We've grown to the point
> where payroll is becoming too complicated to do manually any more, so I'm
> looking at contracting a programmer to create a bespoke C/C++ payroll
> application for us.
>
> In order to save on licensing costs I'm planning to use either lcc or
> gcc/Eclipse as a free alternative to Visual Studio. Can anyone confirm
> whether these compilers support the following key technologies: Windows
> API, Windows Forms, MFC, .NET and OLE.
QuickBooks from Intuit is what... $200?
FCOL.
> Any other comments and suggestions would be appreciated.
Next time, try Google
Keith Thompson
> where payroll is becoming too complicated to do manually any more, so I'm
> looking at contracting a programmer to create a bespoke C/C++ payroll
> application for us.
How many existing payroll applications are out there? (Personally I
have no idea, but I'm sure there are plenty.) What makes you think
using one of them won't be faster, easier, and cheaper than hiring
someone to reinvent the wheel for you?
Richard Heathfield
> Dear Forum:
>
> I run a small business based out of Phoenix, AZ. We've grown to
> the point where payroll is becoming too complicated to do manually
> any more, so I'm looking at contracting a programmer to create a
> bespoke C/C++ payroll application for us.
The most expensive version of Sage I could find quickly was �1739 (I
don't know what the exchange rate is right now, but it doesn't
really matter for this purpose). Contract rates vary wildly but a
reasonably expert C++ programmer is going to cost you in the order
of �50 an hour. 1739 / 50 = a little under 35 hours - basically a
working week. Within that week, your contractor will have:
a) found the toilets and fire exits;
b) set up his desktop to his liking;
c) installed the C++ compiler;
d) asked you a few basic questions about the features you want;
e) drawn a few diagrams.
> In order to save on licensing costs I'm planning to use either lcc
> or gcc/Eclipse as a free alternative to Visual Studio.
Forget it. Use Sage - or any other accounting package of reasonable
pedigree.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Forged article? See
http://www.cpax.org.uk/prg/usenet/comp.lang.c/msgauth.php
"Usenet is a strange place" - dmr 29 July 1999
Walter Banks
"Robert T. Hannis" wrote:
It is a build or buy decision. Cost out specifying and implementing a payroll
system and writing and debugging 10-40K lines of code and balance it against
a package like Quick books which costs about as much as reading your email
this week. The amount you will save in being able to give your accounting
firm data in a standard format will more than pay for itself.
w..
BartC
"Robert T. Hannis" <nos...@nospam.com> wrote in message
news:h23gd8$clu$1...@aioe.org...
> I run a small business based out of Phoenix, AZ. We've grown to the point
> where payroll is becoming too complicated to do manually any more, so I'm
> looking at contracting a programmer to create a bespoke C/C++ payroll
> application for us.
>
> In order to save on licensing costs I'm planning to use either lcc or
> gcc/Eclipse as a free alternative to Visual Studio. Can anyone confirm
> whether these compilers support the following key technologies: Windows
> API, Windows Forms, MFC, .NET and OLE.
Probably a joke post but all you need for payroll is any 1980s computer,
BASIC, and a couple of spare weekends.
--
Bart
Richard Heathfield
>
> "Robert T. Hannis" <nos...@nospam.com> wrote in message
> news:h23gd8$clu$1...@aioe.org...
>
>> I run a small business based out of Phoenix, AZ. We've grown to
>> the point where payroll is becoming too complicated to do
>> manually any more, so I'm looking at contracting a programmer to
>> create a bespoke C/C++ payroll application for us.
>>
>> [...]
>
> Probably a joke post but all you need for payroll is any 1980s
> computer, BASIC, and a couple of spare weekends.
Oh, and the latest tax tables. All ten squillion pages of them. And
updated every year. Sometimes twice a year.
Buy a package. It's less likely to get you into trouble.
Richard
Except Windows...
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
Edwin van den Oetelaar
Take into account also the "legal compliance issues" and accountability.
It would be easier and less expensive and less risky to just let a payroll outsourcing firm handle it.
Just my opinion.
Edwin
Kelsey Bjarnason
On Sat, 27 Jun 2009 01:23:28 +0200, jacob navia wrote:
> If you use C+ Windows API you aren't tied to anybody.
Really? Where do I get the Windows API for my Commodore 64? Or even for
my laptop, which runs Ubuntu?
user923005
> [snips]
>
> On Sat, 27 Jun 2009 01:23:28 +0200, jacob navia wrote:
> > If you use C+ Windows API you aren't tied to anybody.
Actually, you will be tied to Bill Gates, nose to nose, and you will
smell his coffee breath.
> Really? Where do I get the Windows API for my Commodore 64?
At least you can go the other way:
http://www.ccs64.com/
> Or even for
> my laptop, which runs Ubuntu?
Needs a glass of Wine.
You can (of course) run it on:
ATMs
Barcode and RFID Scanners
Digital Picture Frames
Digital Media Adapters
Feature Phones
Fuel Pumps (No wonder they are so freaky in Oregon)
Gaming Devices
GPS
Handheld Terminals
Home/building Automation Gateways
Industrial Controls
Intelligent Appliances
Mini-Kiosks
Mobile Point of Service
Monitoring Devices
Networked Media Devices
Media Servers
Remote Metering
Set-top Boxes
Smart Media Controls
Thin Clients
Voice over Internet Protocol (VoIP) Phones
Windows SideShow
but it requires one of these 4 processor families:
ARM
MIPS
SH4
x86
Beej Jorgensen
>Really? Where do I get the Windows API for my Commodore 64? Or even
>for my laptop, which runs Ubuntu?
For that, you use winelib from http://winehq.com/ . I don't think
there's a C64 port, but you could always try to start one. :)
-Beej
Flash Gordon
I know a company that decided to get someone they knew to build them a
payroll system. After spending a lot of money on it they realised it was
going to be cheaper to throw away all of the money they had already
spent and buy in an off-the-shelf package and pay someone to configure
it for them. So I agree entirely that buying something in will be FAR
cheaper.
Alternatively, give me a contract at half the rate my company currently
hires me out, paid up a year in advance, for one C developer to work 8
hours a day 5 days a week on developing it, and I'll take round it down
to 10000UKP for the first year and I may well take the contract. You
will, of course, need to pay me on an on-going basis for maintenance
(including new government requirements), and because I'm doing it half
price I'll expect to maintain full ownership (so you can't get rid of me).
Oh, and does anyone want a job as a C programmer at 45000UKP per annum
working for a very small company? ;-)
--
Flash Gordon
jacob navia
If you program for Ubuntu you are tied to GTK or to QT.
Obviously that is "free" software and windows is not "free".
But you are tied anyway.
And if you throw away 99% of your program and rewrite
it in ISO C you are ... tied to ISO C!
But this is obvious to anyone. WIndows hasn't got
a good press here, that's all.
jacob navia
> On Jun 29, 6:07 am, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
>> [snips]
>>
>> On Sat, 27 Jun 2009 01:23:28 +0200, jacob navia wrote:
>>> If you use C+ Windows API you aren't tied to anybody.
>
> Actually, you will be tied to Bill Gates, nose to nose, and you will
> smell his coffee breath.
>
>> Really? Where do I get the Windows API for my Commodore 64?
>
> At least you can go the other way:
> http://www.ccs64.com/
>
>> Or even for
>> my laptop, which runs Ubuntu?
>
> Needs a glass of Wine.
>
> You can (of course) run it on:
> ATMs
Most ATMs in France run under windows 2000
Windows runs most ticket vending machines in the
Metro of Paris (I wrote some device drivers for them).
You can find windows machines in many embedded
applications. And in smaller one you will find
the 286/MSDOS combination hard to beat.
Richard Heathfield
> Kelsey Bjarnason wrote:
>> [snips]
>>
>> On Sat, 27 Jun 2009 01:23:28 +0200, jacob navia wrote:
>>
>>> If you use C+ Windows API you aren't tied to anybody.
>>
>> Really? Where do I get the Windows API for my Commodore 64? Or
>> even for my laptop, which runs Ubuntu?
>>
>
> If you program for Ubuntu you are tied to GTK or to QT.
Right.
> Obviously that is "free" software and windows is not "free".
Right again.
> But you are tied anyway.
And again.
> And if you throw away 99% of your program and rewrite
> it in ISO C you are ... tied to ISO C!
But here I disagree. If you write 99% of your program in ISO C (and
yes, 99% is about the right figure), and put the other 1%, the
non-portable stuff, into its own module(s), then you can rewrite
that 1% for each new platform you need to support, which is a darn
sight faster than rewriting the whole thing, which means you aren't
tied to anything.
This point has been made dozens of times before in this newsgroup,
which makes me wonder whether you actually bother to read it.
> But this is obvious to anyone.
Obvious, perhaps - but certainly wrong. Writing portable code does
not tie you to anything in any meaningful sense.
> WIndows hasn't got a good press here, that's all.
My own view is that the Win32 API is a lot of fun to write code for,
and /that's/ a view I've expressed many times before too. Do you
actually read this group?
Flash Gordon
> Kelsey Bjarnason wrote:
>> [snips]
>>
>> On Sat, 27 Jun 2009 01:23:28 +0200, jacob navia wrote:
>>
>>> If you use C+ Windows API you aren't tied to anybody.
>>
>> Really? Where do I get the Windows API for my Commodore 64? Or even
>> for my laptop, which runs Ubuntu?
>>
>
> If you program for Ubuntu you are tied to GTK or to QT.
Rubbish. For a start there is all the KDE based software available for
Ubuntu (including a version of Ubuntu that uses KDE instead of Gnome as
the Desktop). Then there are all the other GUI front ends.
> Obviously that is "free" software and windows is not "free".
Yes. More importantly it is not tied to one particular OS.
> But you are tied anyway.
You are tied to the systems supported by the GUI you use. Windows is
only available in Windows (well, there are emulation layers, but they
were less than perfect last time I checked).
> And if you throw away 99% of your program and rewrite
> it in ISO C you are ... tied to ISO C!
Which is more widely portable than almost anything else.
> But this is obvious to anyone. WIndows hasn't got
> a good press here, that's all.
There are GUI toolkits which run on top of Windows and other OSs.
Including GTK (one Windows application I like and use a lot is built in
GTK).
People were correcting your claim that, "If you use C+ Windows API you
aren't tied to anybody" which is clearly rubbish.
--
Flash Gordon
Richard Bos
> On Jun 29, 6:07=A0am, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
>
> > On Sat, 27 Jun 2009 01:23:28 +0200, jacob navia wrote:
> > > If you use C+ Windows API you aren't tied to anybody.
>
> Actually, you will be tied to Bill Gates, nose to nose, and you will
> smell his coffee breath.
Coffee? In Seattle? Where?
Richard
Tom St Denis
> If you program for Ubuntu you are tied to GTK or to QT.
> Obviously that is "free" software and windows is not "free".
Just to torpedo whatever point you're trying to make here... GTK+ has
been ported to Windows for a long time. So no, my "Linux" application
using GTK+ is not Linux only.
However, my GDI application in Win32 is limited to Windows only [well
technically there is some support via wine but that's not official].
> But you are tied anyway.
>
> And if you throw away 99% of your program and rewrite
> it in ISO C you are ... tied to ISO C!
But the point is a proper platform will offer a choice of ISO C
conforming compilers. It's hardly our fault Windows doesn't come
standard with a C compiler (or POSIX compatible runtime for that
matter)
> But this is obvious to anyone. WIndows hasn't got
> a good press here, that's all.
I don't know about that in c.l.c specifically, but I don't see why it
deserves good press anyways. If you're in anyway used to a typical
UNIX/Linux workstation going back to Windows is VERY VERY PAINFUL.
From the backwards slashes for directories, to the lack of a proper
shell, to the lack of a proper desktop, or development tools, or
userland tools [gzip, tar, grep, perl, sed, awk, etc]... I just don't
get why anyone would evangelize Windows at all. Even if it were free
I'd still not want to use it.
To circle around to topicality ... we shouldn't strive for
diversification in the compiler or library standards, we should strive
for diversification in their IMPLEMENTATION. I should be able to
write an ISO C application that runs anywhere with the appropriate
facilities [ram, processing power, disk space, etc] and not worry
about what elements of the C standard or library standards the host
platform vendor has cherry picked to implement. How that stuff
actually gets implemented behind the scenes is another question and I
value diversity there as competition brings out superior
implementations. But they should all be striving for the same
compliance with the standards.
There isn't a really big reason why Microsoft hasn't worked closer
with say the Cygwin folk to integrate [properly and not ad hoc like as
current] a POSIX standard layer on top of their Win32api. Imagine if
you could easily open up the entire catalogue of open source tools to
the Windows platform without resorting to massive porting efforts.
Then, maybe, the OS might be worth looking into.
Tom
Richard Heathfield
> jacob navia wrote:
>> Kelsey Bjarnason wrote:
>>> [snips]
>>>
>>> On Sat, 27 Jun 2009 01:23:28 +0200, jacob navia wrote:
>>>
>>>> If you use C+ Windows API you aren't tied to anybody.
>>>
>>> Really? Where do I get the Windows API for my Commodore 64? Or
>>> even for my laptop, which runs Ubuntu?
>>>
>>
>> If you program for Ubuntu you are tied to GTK or to QT.
>
> Rubbish. For a start there is all the KDE based software available
> for Ubuntu (including a version of Ubuntu that uses KDE instead of
> Gnome as the Desktop). Then there are all the other GUI front
> ends.
In which case you're tied to those instead. You have not nullified
Jacob Navia's point, merely modified it slightly.
>> Obviously that is "free" software and windows is not "free".
>
> Yes. More importantly it is not tied to one particular OS.
Nor, alas, is it implemented on /every/ platform. So you can
palliate portability problems, but not eliminate them.
>> But you are tied anyway.
>
> You are tied to the systems supported by the GUI you use. Windows
> is only available in Windows (well, there are emulation layers,
> but they were less than perfect last time I checked).
This needn't be such a huge problem, actually, if you are careful to
isolate the non-portable parts of the program. I have worked on one
project where this was done extremely effectively, by dint of some
pretty darn good programming, but one can get reasonable returns
simply by separating "business logic" from "presentation logic".
>> And if you throw away 99% of your program and rewrite
>> it in ISO C you are ... tied to ISO C!
>
> Which is more widely portable than almost anything else.
Right.
<snip>
> People were correcting your claim that, "If you use C+ Windows API
> you aren't tied to anybody" which is clearly rubbish.
Um, it's not rubbish when seen from the perspective of someone who
only uses one platform and cannot conceive of the need to use any
other platform.
Nick Keighley
> On Jun 29, 7:42 pm, jacob navia <ja...@jacob.remcomp.fr> wrote:
> > If you program for Ubuntu you are tied to GTK or to QT.
> > Obviously that is "free" software and windows is not "free".
>
> Just to torpedo whatever point you're trying to make here... GTK+ has
> been ported to Windows for a long time. So no, my "Linux" application
> using GTK+ is not Linux only.
>
> However, my GDI application in Win32 is limited to Windows only [well
> technically there is some support via wine but that's not official].
>
> > But you are tied anyway.
>
> > And if you throw away 99% of your program and rewrite
> > it in ISO C you are ... tied to ISO C!
>
> But the point is a proper platform will offer a choice of ISO C
> conforming compilers. It's hardly our fault Windows doesn't come
> standard with a C compiler (or POSIX compatible runtime for that
> matter)
>
> > But this is obvious to anyone. WIndows hasn't got
> > a good press here, that's all.
>
> I don't know about that in c.l.c specifically, but I don't see why it
> deserves good press anyways. If you're in anyway used to a typical
> UNIX/Linux workstation going back to Windows is VERY VERY PAINFUL.
I regularly hop backwards and forwards. It's not that bad.
The first time I used unix I hated it!
> From the backwards slashes for directories,
windows accepts forward slash most places. The DOS shell
is one irritating area that doesn't. And I bet that's fixable.
I trip up the other way when Unix demands I get the case right.
> to the lack of a proper shell,
fair point. I use perl or python
> to the lack of a proper desktop,
que? I've got a better desktop on windows than I have on any
of the three unix I use.
> or development tools,
que? Like what?
> or
> userland tools [gzip, tar, grep, perl, sed, awk, etc]
pkzip does the same job as gzip and tar
perl works fine on windows
I never got on with sed and I use perl instead of awk
grep you have a point. But my home disk is visible to both
unix and windows so it hardly ever matter.
> ... I just don't
> get why anyone would evangelize Windows at all.
I wouldn't let a naive user near any form of unix I've seen.
Windows works ok if you leave it alone.
> Even if it were free I'd still not want to use it.
>
> To circle around to topicality ... we shouldn't strive for
> diversification in the compiler or library standards, we should strive
> for diversification in their IMPLEMENTATION. I should be able to
> write an ISO C application that runs anywhere with the appropriate
> facilities [ram, processing power, disk space, etc] and not worry
> about what elements of the C standard or library standards the host
> platform vendor has cherry picked to implement.
too right!
> How that stuff
> actually gets implemented behind the scenes is another question and I
> value diversity there as competition brings out superior
> implementations. But they should all be striving for the same
> compliance with the standards.
>
> There isn't a really big reason why Microsoft hasn't worked closer
> with say the Cygwin folk to integrate [properly and not ad hoc like as
> current] a POSIX standard layer on top of their Win32api.
that is disappointing. DEC manages to get OpenVms to be Posix
compliant why can't windows. because they don't care.
luserXtrog
I've read very good things about Espresso Vivace.
The owner literally wrote the book about espresso.
No comment about other places.
--
lxt
Kelsey Bjarnason
Actually, wine's only a partial implementation; while lots of winapps
work under it, lots don't.
BartC
"Richard Heathfield" <r...@see.sig.invalid> wrote in message
news:_9qdnbc6rMDjktfX...@bt.com...
> Flash Gordon said:
>
>> jacob navia wrote:
>> People were correcting your claim that, "If you use C+ Windows API
>> you aren't tied to anybody" which is clearly rubbish.
>
> Um, it's not rubbish when seen from the perspective of someone who
> only uses one platform and cannot conceive of the need to use any
> other platform.
Or when the majority of customers happen to use one platform. Windows
machines were very easy to buy, get working and find support for, unlike
anything with Linux (that may have changed recently).
--
Bart
Flash Gordon
> Flash Gordon said:
>
>> jacob navia wrote:
>>> Kelsey Bjarnason wrote:
>>>> [snips]
>>>>
>>>> On Sat, 27 Jun 2009 01:23:28 +0200, jacob navia wrote:
>>>>
>>>>> If you use C+ Windows API you aren't tied to anybody.
>>>> Really? Where do I get the Windows API for my Commodore 64? Or
>>>> even for my laptop, which runs Ubuntu?
>>>>
>>> If you program for Ubuntu you are tied to GTK or to QT.
>> Rubbish. For a start there is all the KDE based software available
>> for Ubuntu (including a version of Ubuntu that uses KDE instead of
>> Gnome as the Desktop). Then there are all the other GUI front
>> ends.
>
> In which case you're tied to those instead. You have not nullified
> Jacob Navia's point, merely modified it slightly.
I missed that Jacob mentioned QT, but my point stands, at least as I
read what he said. Using Ubuntu does not tie you to a particular GUI or
toolkit (or a small range of them). There are a large range available.
Now, of course, if you tie yourself to GTK you are tied to GTK, but that
is not what Jacob said, has no real relation to Ubuntu, and does not
even tie you to flavours of Unix.
>>> Obviously that is "free" software and windows is not "free".
>> Yes. More importantly it is not tied to one particular OS.
>
> Nor, alas, is it implemented on /every/ platform. So you can
> palliate portability problems, but not eliminate them.
Agreed. However, it is the increased portability that give it a big
advantage over the Windows API (when you are targeting Windows that is
normally what you customers already have, so making use of the Windows
API does not mean spending more money with MS than would be spent anyway).
>>> But you are tied anyway.
>> You are tied to the systems supported by the GUI you use. Windows
>> is only available in Windows (well, there are emulation layers,
>> but they were less than perfect last time I checked).
>
> This needn't be such a huge problem, actually, if you are careful to
> isolate the non-portable parts of the program. I have worked on one
> project where this was done extremely effectively, by dint of some
> pretty darn good programming, but one can get reasonable returns
> simply by separating "business logic" from "presentation logic".
I agree you can do it. In fact, with a well written client-server
application the "presentation logic" will be running on a different box
to the "business logic", so it's not only possible it's done! If course,
you then have to isolate the network handling, but that is even easier.
<snip>
>> People were correcting your claim that, "If you use C+ Windows API
>> you aren't tied to anybody" which is clearly rubbish.
>
> Um, it's not rubbish when seen from the perspective of someone who
> only uses one platform and cannot conceive of the need to use any
> other platform.
It may be how it appears to someone like that, but how it appears to
them does not alter the fact that it is still tied to Microsoft!
--
Flash Gordon
Antoninus Twink
> But here I disagree. If you write 99% of your program in ISO C (and
> yes, 99% is about the right figure), and put the other 1%, the
> non-portable stuff, into its own module(s), then you can rewrite
> that 1% for each new platform you need to support, which is a darn
> sight faster than rewriting the whole thing, which means you aren't
> tied to anything.
Yeah, sure, Heathfield.
As usual, you expect us to believe that you are a super-programmer who
is not bound by the same limitations as us mere mortals. In fact, all we
conclude is that you have *no* significant real-world programming
experience.
So you can write a GUI application like the payroll suite the OP was
interested in, and put 99% of the core functionality into a portable
library with only 1% non-portable code to support the GUI?
I call bullshit.
Just assembling the main window will be tens or hundreds of lines of
code. Tens of widgets all need their own set of callback functions. And
this all comes to 1% of the code?
Bullshit. Simple, unadulterated bullshit.
jacob navia
True, but since noooone of the regs knows anything about GUI programming
he can say anything he wants. They will always agree.
Kenneth Brody
> On 30 Jun 2009 at 6:17, Richard Heathfield wrote:
>> But here I disagree. If you write 99% of your program in ISO C (and
>> yes, 99% is about the right figure), and put the other 1%, the
>> non-portable stuff, into its own module(s), then you can rewrite
>> that 1% for each new platform you need to support, which is a darn
>> sight faster than rewriting the whole thing, which means you aren't
>> tied to anything.
>
> Yeah, sure, Heathfield.
>
> As usual, you expect us to believe that you are a super-programmer who
> is not bound by the same limitations as us mere mortals. In fact, all we
> conclude is that you have *no* significant real-world programming
> experience.
>
> So you can write a GUI application like the payroll suite the OP was
> interested in, and put 99% of the core functionality into a portable
> library with only 1% non-portable code to support the GUI?
Well, I don't write GUI, but if you take Richard's post and "s/ISO C/ISO C
plus POSIX/", then it pretty much matches the several-hundred-thousand-line
"real world" app I help maintain and develop. (In fact, 99% may be a little
low.)
--
Kenneth Brody
Gordon Burditt
>interested in, and put 99% of the core functionality into a portable
>library with only 1% non-portable code to support the GUI?
I believe 99% of the work of writing a *PAYROLL* application is
getting all the government information (such as tax withholding)
for all 50 states, and who knows how many cities and counties, and
keeping it up to date. An international payroll program would be
many, many times worse. Most of this may not even be code - it's
probably best represented as data tables, and maybe stored in
external files. In addition, there are company-local variations
in deductions for things such as union dues (for how many different
unions?) and health insurance (how many different plans, and coverage
options? (employee only/employee+spouse/family))
Richard Heathfield
And of course none of this information or logic depends on the
platform you're using.
Richard Heathfield
<snip>
> Well, I don't write GUI, but if you take Richard's post and "s/ISO
> C/ISO C plus POSIX/", then it pretty much matches the
> several-hundred-thousand-line
> "real world" app I help maintain and develop. (In fact, 99% may
> be a little low.)
If you allow POSIX too, then yes, you could improve on 99% without
too much difficulty.
My example, by the way, was a 500KLOC Web browser for set-top boxes
(which I've mentioned before in similar discussions), of which
5KLOC needed to be rewritten for each new port. When I was working
there, the browser was being ported to new platforms several times
per year.
Kelsey Bjarnason
On Tue, 30 Jun 2009 06:17:26 +0000, Richard Heathfield wrote:
>> If you program for Ubuntu you are tied to GTK or to QT.
>
> Right.
News to me.
QT and GTK are but two of several approaches one can use. For another,
one can use a web-based interface, which would mean the UI side works on
virtually any (or, at least, virtually any GUI-based) platform.
Or one can uses curses, producing a widely portable text interface.
Aside from those, we have, off the top of the head...
WxWindows, Swing, WinForms (via mono), OpenGL if one's doing that sort of
thing, xul, FOX, undoubtedly several more. Note that several available
options are cross-platform or nearly so (i.e. trivial mods rather than
complete UI rewrites).
Kelsey Bjarnason
On Tue, 30 Jun 2009 01:42:59 +0200, jacob navia wrote:
> Kelsey Bjarnason wrote:
>> [snips]
>>
>> On Sat, 27 Jun 2009 01:23:28 +0200, jacob navia wrote:
>>
>>> If you use C+ Windows API you aren't tied to anybody.
>>
>> Really? Where do I get the Windows API for my Commodore 64? Or even
>> for my laptop, which runs Ubuntu?
>>
>>
> If you program for Ubuntu you are tied to GTK or to QT.
News to me. Where did you dig up that bit of nonsense?
> Obviously that
> is "free" software and windows is not "free".
I suspect you misunderstand "free" as used in "free software" - it's
"free as in liberty, not as in beer".
> And if you throw away 99% of your program and rewrite it in ISO C you
> are ... tied to ISO C!
Which means my code works on virtually every platform known to man. I'll
take that risk.
Now, where do I get a full, working copy of the WinAPI for my C64... or
are you still maintaining that using the WinAPI doesn't mean your code is
tied to a particular platform?
Mark McIntyre
>
> If you program for Ubuntu you are tied to GTK or to QT.
or any of a host of other platform-neutral possibilities.
> Obviously that is "free" software and windows is not "free".
> But you are tied anyway.
In an entirely different sense of the word. Unlike say, gtk, which can
be run on pretty much any OS, the Windows API is available only for
windows.
> But this is obvious to anyone. WIndows hasn't got
> a good press here, that's all.
Nonsense. Its just that Windows shouldn't even get discussed here. Nor
should gtk or qt or X or....
--
Mark McIntyre
CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Mark McIntyre
>
> True, but since noooone of the regs knows anything about GUI programming
Based on what? That they don't talk about it in CLC?
On that basis, it seems you know nothing about the French language,
since you never talk about it here. And RJH knows nothing about
childcare, since he never talks about it here. And I know nothing about
Oxford or London, since I never talk about them here.
Fail.
Richard Heathfield
> [snips]
>
> On Tue, 30 Jun 2009 06:17:26 +0000, Richard Heathfield wrote:
>
>>> If you program for Ubuntu you are tied to GTK or to QT.
>>
>> Right.
>
> News to me.
Well, okay, right-*ish*.
> QT and GTK are but two of several approaches one can use. For
> another, one can use a web-based interface, which would mean the
> UI side works on virtually any (or, at least, virtually any
> GUI-based) platform.
But not MS-DOS (which is perhaps no big deal) or typical mainframe
installations (which is, at least from my point of view).
Nevertheless, Jacob Navia's point can be generalised to make it more
true: if you tie yourself to a particular GUI toolkit, you are tied
to that particular GUI toolkit. :-)
Beej Jorgensen
>Just assembling the main window will be tens or hundreds of lines of
>code. Tens of widgets all need their own set of callback functions. And
>this all comes to 1% of the code?
You might be underestimating the complexity of payroll-related law in
certain countries. ;-)
-Beej
Lew Pitcher
>
> "Robert T. Hannis" <nos...@nospam.com> wrote in message
> news:h23gd8$clu$1...@aioe.org...
>
>> I run a small business based out of Phoenix, AZ. We've grown to the point
>> where payroll is becoming too complicated to do manually any more, so I'm
>> looking at contracting a programmer to create a bespoke C/C++ payroll
>> application for us.
>>
>> In order to save on licensing costs I'm planning to use either lcc or
>> gcc/Eclipse as a free alternative to Visual Studio. Can anyone confirm
>> whether these compilers support the following key technologies: Windows
>> API, Windows Forms, MFC, .NET and OLE.
>
> Probably a joke post but all you need for payroll is any 1980s computer,
> BASIC, and a couple of spare weekends.
I see that you've never written a payroll program for a SME, let alone a
large company. Such a program (a suite, actually) does more than multiply
hours worked by hourly rate (think withholding taxes, pension payments,
[Un]Employment insurance, union dues, overtime rates, vacation days, etc],
and quite often has major hooks into the enterprise Human Resources tools.
Four mandays of BASIC development won't cut it.
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
Flash Gordon
> On June 27, 2009 05:20, in comp.lang.c, BartC (ba...@freeuk.com) wrote:
<snip>
>> Probably a joke post but all you need for payroll is any 1980s computer,
>> BASIC, and a couple of spare weekends.
>
> I see that you've never written a payroll program for a SME, let alone a
> large company. Such a program (a suite, actually) does more than multiply
> hours worked by hourly rate (think withholding taxes, pension payments,
> [Un]Employment insurance, union dues, overtime rates, vacation days, etc],
> and quite often has major hooks into the enterprise Human Resources tools.
You forgot the interface to the accounts package, possibly interfaces to
project cost management software (something I've done from the other
side), possibly and interface to BACS or some other electronic banking
system...
> Four mandays of BASIC development won't cut it.
4 man-days might not be enough to make a serious start on reading up on
the interfacing requirements.
--
Flash Gordon
Mark McIntyre
> Antoninus Twink <nos...@nospam.invalid> wrote:
>> Just assembling the main window will be tens or hundreds of lines of
>> code.
huh? Maybe in some arcane UI such as Win32, but in most high level UIs
it takes a few lines.
>>Tens of widgets all need their own set of callback functions. And
>> this all comes to 1% of the code?
>
> You might be underestimating the complexity of payroll-related law in
> certain countries. ;-)
And payroll systems typically have to handle multiple countries.
GPS
>
> "Robert T. Hannis" <nos...@nospam.com> wrote in message
> news:h23gd8$clu$1...@aioe.org...
>
>> I run a small business based out of Phoenix, AZ. We've grown to the point
>> where payroll is becoming too complicated to do manually any more, so I'm
>> looking at contracting a programmer to create a bespoke C/C++ payroll
>> application for us.
>>
>> In order to save on licensing costs I'm planning to use either lcc or
>> gcc/Eclipse as a free alternative to Visual Studio. Can anyone confirm
>> whether these compilers support the following key technologies: Windows
>> API, Windows Forms, MFC, .NET and OLE.
>
> Probably a joke post but all you need for payroll is any 1980s computer,
> BASIC, and a couple of spare weekends.
>
I shared your perception of payroll programming, until I read this:
http://www.c2.com/cgi/wiki?WhyIsPayrollHard
-George
user923005
Tax laws
Overseas workers
Legal compliance
GAAP verification of correctness
When you think about it, it is something that pretty well has to be
perfect in every single aspect.
Antoninus Twink
> Antoninus Twink <nos...@nospam.invalid> wrote:
>> Just assembling the main window will be tens or hundreds of lines of
>> code.
>
> huh? Maybe in some arcane UI such as Win32, but in most high level UIs
> it takes a few lines.
Are you joking?
The only way I know of specifying a form in any library in a few lines
is to design the form in some GUI beforehand, thereby sacrificing a lot
of control over how the form looks and where its widgets get placed,
besides being a slow and clumsy way of doing things.
Squeamizh
I am not sure what is meant by "assembling" the main window, but
regardless of the meaning, saying you can do it in a few lines
certainly sounds ridiculous.
Perhaps this is all just some big misunderstanding, and Mark McIntyre
can provide an example of what he's talking about. If it only takes a
few lines, then demonstrating his point should be trivial.
jacob navia
> Beej Jorgensen wrote:
>> Antoninus Twink <nos...@nospam.invalid> wrote:
>>> Just assembling the main window will be tens or hundreds of lines of
>>> code.
>
> huh? Maybe in some arcane UI such as Win32, but in most high level UIs
> it takes a few lines.
Sure. This confirms what I have said all along:
regs do not have a clue of what is GUI programming.
Since it is only a few lines, just give us an example please.
I can give you an example:
#include <stdio.h>
int main(void)
{
printf("hello\n");
system("pause");
}
will provoke the opening of a DOS window...
:-)
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Mark McIntyre
> I am not sure what is meant by "assembling" the main window, but
> regardless of the meaning, saying you can do it in a few lines
> certainly sounds ridiculous.
>
> Perhaps this is all just some big misunderstanding, and Mark McIntyre
> can provide an example of what he's talking about.
Sure. I have an app that pops up a window, displays an analogue clock,
and counts down from some point defined by the commandline, before
beeping thrice and exiting. It takes 40 lines.
> If it only takes a
> few lines, then demonstrating his point should be trivial.
Well, I was responding to a troll, and he took my bait, and you
responded to his further trolling, so....
But the point is, if the HLL you're using provides suitable features you
can do it easily. Win32 on its own is too low level to offer this sort
of sopistication but there are plenty of higher-level UI libs that do.
These also have the advantage that they work on different underlying
graphical display subsystems, The above 40-liner would work on Windows
(95-Vista), X-11, MacOs, DecWindows, and probably a bunch of others.
Mark McIntyre
> Mark McIntyre wrote:
>> Beej Jorgensen wrote:
>>> Antoninus Twink <nos...@nospam.invalid> wrote:
>>>> Just assembling the main window will be tens or hundreds of lines of
>>>> code.
>>
>> huh? Maybe in some arcane UI such as Win32, but in most high level UIs
>> it takes a few lines.
>
> Sure. This confirms what I have said all along:
Which of the many nonsensical things? That RJH is out to get you? That
Keith hates your guts?
> regs do not have a clue of what is GUI programming.
Oh, that piece of arrant nonsense. Cluefest: the fact that none of hte
regulars posts GUI programming snippets here means nothing. Wander over
to the relevant groups, note the posts by CLC regulars, then come back
and apologise. I won't hold my breath though.
> Since it is only a few lines, just give us an example please.
No. If you're too inept to STFW to find examples of how to use other
graphics interfaces than Win32, I am not going to help.
Meantime try reading the documentation for tk.
Keith Thompson
> Squeamizh wrote:
>> I am not sure what is meant by "assembling" the main window, but
>> regardless of the meaning, saying you can do it in a few lines
>> certainly sounds ridiculous.
>>
>> Perhaps this is all just some big misunderstanding, and Mark McIntyre
>> can provide an example of what he's talking about.
>
> Sure. I have an app that pops up a window, displays an analogue clock,
> and counts down from some point defined by the commandline, before
> beeping thrice and exiting. It takes 40 lines.
40 lines of what?
[...]
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Squeamizh
wrote:
> Squeamizh wrote:
> > I am not sure what is meant by "assembling" the main window, but
> > regardless of the meaning, saying you can do it in a few lines
> > certainly sounds ridiculous.
>
> > Perhaps this is all just some big misunderstanding, and Mark McIntyre
> > can provide an example of what he's talking about.
>
> Sure. I have an app that pops up a window, displays an analogue clock,
> and counts down from some point defined by the commandline, before
> beeping thrice and exiting. It takes 40 lines.
Antoninus said it would take "tens or hundreds of lines." I'm having
a difficult time understanding how that criterion doesn't fit your 40-
line example.
>
> > If it only takes a
> > few lines, then demonstrating his point should be trivial.
>
> Well, I was responding to a troll, and he took my bait, and you
> responded to his further trolling, so....
If that is your interpretation of events, then the only troll here is
you.
Nobody
>>> Just assembling the main window will be tens or hundreds of lines of
>>> code.
>>
>> huh? Maybe in some arcane UI such as Win32, but in most high level UIs
>> it takes a few lines.
>
> Are you joking?
>
> The only way I know of specifying a form in any library in a few lines
> is to design the form in some GUI beforehand,
You don't have to use a GUI, but the sane way to design a UI is with
a data file, not dozens of create_widget() calls.
> thereby sacrificing a lot
> of control over how the form looks and where its widgets get placed,
You're thinking of Windows, where everything is placed at fixed
coordinates. Unix UI builders (Glade, UIL) specify relative placements,
with the final positions determined by the container's packing algorithm,
the same as if you create the widgets in the code.
> besides being a slow and clumsy way of doing things.
It's hard to get much slower or clumsier than creating the UI
programmatically.
Richard Bos
> BartC wrote:
>
> > Probably a joke post but all you need for payroll is any 1980s computer,
> > BASIC, and a couple of spare weekends.
>
> I shared your perception of payroll programming, until I read this:
> http://www.c2.com/cgi/wiki?WhyIsPayrollHard
I thought payroll processing was easy. That lasted until I _got_ my
first paycheck, and it suddenly became very important indeed that they
got it right in every last detail.
Richard
Richard Bos
> But the point is, if the HLL you're using provides suitable features you
> can do it easily. Win32 on its own is too low level to offer this sort
> of sopistication but there are plenty of higher-level UI libs that do.
> These also have the advantage that they work on different underlying
> graphical display subsystems, The above 40-liner would work on Windows
> (95-Vista), X-11, MacOs, DecWindows, and probably a bunch of others.
Possibly, but would it look like a normal Windows program, an X-11
program, the usual MacOs program and a standard DecWindows program
respectively, or would it look like a *shudder* JavaApp on all of them?
Richard
Mark McIntyre
> On Jul 2, 3:49 pm, Mark McIntyre <markmcint...@TROUSERSspamcop.net>
> wrote:
>> Squeamizh wrote:
>>> I am not sure what is meant by "assembling" the main window, but
>>> regardless of the meaning, saying you can do it in a few lines
>>> certainly sounds ridiculous.
>>> Perhaps this is all just some big misunderstanding, and Mark McIntyre
>>> can provide an example of what he's talking about.
>> Sure. I have an app that pops up a window, displays an analogue clock,
>> and counts down from some point defined by the commandline, before
>> beeping thrice and exiting. It takes 40 lines.
>
> Antoninus said it would take "tens or hundreds of lines." I'm having
> a difficult time understanding how that criterion doesn't fit your 40-
> line example.
I said it would take just a few. I'm having a difficult time
understanding how that criterion doesn't fit my 40 line example.
By the way 40 lines is the /entire programme/. The window part of it was
only a few.
> If that is your interpretation of events, then the only troll here is
> you.
Evidently you've not been around long enough to spot Twink's trolling.
>> But the point is, if the HLL you're using provides suitable features you
>> can do it easily. Win32 on its own is too low level to offer this sort
>> of sopistication but there are plenty of higher-level UI libs that do.
>> These also have the advantage that they work on different underlying
>> graphical display subsystems, The above 40-liner would work on Windows
>> (95-Vista), X-11, MacOs, DecWindows, and probably a bunch of others.
I notice you didn't comment on this part.
Mark McIntyre
> Mark McIntyre <markmc...@TROUSERSspamcop.net> writes:
>> Squeamizh wrote:
>>> I am not sure what is meant by "assembling" the main window, but
>>> regardless of the meaning, saying you can do it in a few lines
>>> certainly sounds ridiculous.
>>>
>>> Perhaps this is all just some big misunderstanding, and Mark McIntyre
>>> can provide an example of what he's talking about.
>> Sure. I have an app that pops up a window, displays an analogue clock,
>> and counts down from some point defined by the commandline, before
>> beeping thrice and exiting. It takes 40 lines.
>
> 40 lines of what?
Perl of course :-)
Hence I'm not proposing to post it here.
But it could as easily be C - you just need a suitable library of
widgets and code along the lines of
createwindow(location, size, colour);
addbutton(title, location, action);
etc
will do it.
Mark McIntyre
Yes.
> or would it look like a *shudder* JavaApp on all of them?
JAVA !^$%! I shhpeet upon your Java, my camel too.
Richard Bos
> Richard Bos wrote:
> > Mark McIntyre <markmc...@TROUSERSspamcop.net> wrote:
> >
> >> But the point is, if the HLL you're using provides suitable features you
> >> can do it easily. Win32 on its own is too low level to offer this sort
> >> of sopistication but there are plenty of higher-level UI libs that do.
> >> These also have the advantage that they work on different underlying
> >> graphical display subsystems, The above 40-liner would work on Windows
> >> (95-Vista), X-11, MacOs, DecWindows, and probably a bunch of others.
> >
> > Possibly, but would it look like a normal Windows program, an X-11
> > program, the usual MacOs program and a standard DecWindows program
> > respectively,
>
> Yes.
Is it, then available for C? I want one of those, but I've only found
one for C++.
Richard
Antoninus Twink
> Sure. I have an app that pops up a window, displays an analogue clock,
> and counts down from some point defined by the commandline, before
> beeping thrice and exiting. It takes 40 lines.
Great.
Give up your trolling, Mackintyre. As you know full well, the context
was a substantial GUI application (specifically a payroll suite), not a
silly little toy with a single window containing a single widget.
Even then, 40 lines for something as simple as that makes my point
pretty well.
Squeamizh
wrote:
> Squeamizh wrote:
> > On Jul 2, 3:49 pm, Mark McIntyre <markmcint...@TROUSERSspamcop.net>
> > wrote:
> >> Squeamizh wrote:
> >>> I am not sure what is meant by "assembling" the main window, but
> >>> regardless of the meaning, saying you can do it in a few lines
> >>> certainly sounds ridiculous.
> >>> Perhaps this is all just some big misunderstanding, and Mark McIntyre
> >>> can provide an example of what he's talking about.
> >> Sure. I have an app that pops up a window, displays an analogue clock,
> >> and counts down from some point defined by the commandline, before
> >> beeping thrice and exiting. It takes 40 lines.
>
> > Antoninus said it would take "tens or hundreds of lines." I'm having
> > a difficult time understanding how that criterion doesn't fit your 40-
> > line example.
>
> I said it would take just a few. I'm having a difficult time
> understanding how that criterion doesn't fit my 40 line example.
This is a good example of how forum discussions often degenerate into
a waste of everyone's time. There seems to always be a certain
element of participants who are either too dishonest or too stupid to
take into account the entire context of a thread before posting. In
this case, you appear to have forgotten what you yourself posted when
you attempted to contradict Antoninus Twink. Now, by agreeing that
your 40-line example does support his claim, you make it obvious that
your motivation was not to spawn an exchange of ideas, but to publicly
argue with someone you dislike. Not true? Then please clarify your
part in the below exchange:
Antoninus Twink: Just assembling the main window will be tens or
hundreds of lines of code.
Mark McIntyre: huh? Maybe in some arcane UI such as Win32, but in most
high level UIs it takes a few lines.
> By the way 40 lines is the /entire programme/. The window part of it was
> only a few.
I asked you for an example, and you provided a vague description of
some perl script. I realize that since you are incapable or unwilling
to consider the appropriate context before opening your big fat mouth,
I'm likely wasting my time, but if you actually go back and read
Antoninus's post, the discussion specifically and explicitly regarded
"ISO C." In addition, the program being discussed is a payroll
application that would actually be used in the real world, not a silly
script which beeps three times (which, I guess you are amused by?).
When I asked you to illuminate your point with an example, I wrongly
assumed you would take some basic context into consideration. Now I
know better.
> > If that is your interpretation of events, then the only troll here is
> > you.
>
> Evidently you've not been around long enough to spot Twink's trolling.
I don't care much about who said something; the substance of what is
actually said is a lot more interesting. If you can't support your
side with a logical argument--and clearly you cannot--then simply
disparaging someone's character is not a valid substitute. What's
more, you admitted that you baited Antoninus somehow, and that he
ended up "taking the bait." That sounds like a plain admission of
trolling to me.
> >> But the point is, if the HLL you're using provides suitable features you
> >> can do it easily. Win32 on its own is too low level to offer this sort
> >> of sopistication but there are plenty of higher-level UI libs that do.
> >> These also have the advantage that they work on different underlying
> >> graphical display subsystems, The above 40-liner would work on Windows
> >> (95-Vista), X-11, MacOs, DecWindows, and probably a bunch of others.
>
> I notice you didn't comment on this part.
My post addressed your claim that it would take only a few lines of
code to build the main window of a GUI. I guess you think you scored
some big points by describing something very obvious that has already
been posted elsewhere in this thread, but you failed to notice that it
is entirely irrelevant.
BartC
> On June 27, 2009 05:20, in comp.lang.c, BartC (ba...@freeuk.com)
> wrote:
>
>>
>> "Robert T. Hannis" <nos...@nospam.com> wrote in message
>> news:h23gd8$clu$1...@aioe.org...
>>
>>> I run a small business based out of Phoenix, AZ. We've grown to the
>>> point where payroll is becoming too complicated to do manually any
>>> more, so I'm looking at contracting a programmer to create a
>>> bespoke C/C++ payroll application for us.
>>>
>>> In order to save on licensing costs I'm planning to use either lcc
>>> or gcc/Eclipse as a free alternative to Visual Studio. Can anyone
>>> confirm whether these compilers support the following key
>>> technologies: Windows API, Windows Forms, MFC, .NET and OLE.
>>
>> Probably a joke post but all you need for payroll is any 1980s
>> computer, BASIC, and a couple of spare weekends.
>
> I see that you've never written a payroll program for a SME, let
> alone a large company. Such a program (a suite, actually) does more
> than multiply hours worked by hourly rate (think withholding taxes,
> pension payments, [Un]Employment insurance, union dues, overtime
> rates, vacation days, etc], and quite often has major hooks into the
> enterprise Human Resources tools.
>
> Four mandays of BASIC development won't cut it.
I've done a wages program for a small company, admittedly one trading on a
small island with simpler rules than the US. And it was part of a larger
system with which it shared some data.
Probably it was even simpler than the Basic code I was suggesting.
For that matter, how was this done on a typical 1980s microcomputer, perhaps
with Basic, and with limited memory? Assuming payroll systems were available
on such machines.
The OP mentioned the work was currently done manually, and any sort of
automation could help.
--
Bart
superpollo
> Keith Thompson wrote:
>
>> Mark McIntyre <markmc...@TROUSERSspamcop.net> writes:
>>
>>> Squeamizh wrote:
>>>
>>>> I am not sure what is meant by "assembling" the main window, but
>>>> regardless of the meaning, saying you can do it in a few lines
>>>> certainly sounds ridiculous.
>>>>
>>>> Perhaps this is all just some big misunderstanding, and Mark McIntyre
>>>> can provide an example of what he's talking about.
>>>
>>> Sure. I have an app that pops up a window, displays an analogue clock,
>>> and counts down from some point defined by the commandline, before
>>> beeping thrice and exiting. It takes 40 lines.
>>
>>
>> 40 lines of what?
>
>
> Perl of course :-)
> Hence I'm not proposing to post it here.
>
> But it could as easily be C - you just need a suitable library of
> widgets
such as ... ?
bye
superpollo
> Meantime try reading the documentation for tk.
TK ??? are there bindings and headers for C ?
hope so.
bye
bartc
"superpollo" <us...@example.net> wrote in message
news:4a65871b$0$1112$4faf...@reader4.news.tin.it...
Apparently. But you won't get any help from the docs for Tk, which tell you
absolutely everything except how to do it!
If you find out how to use Tk stuff from C (without the Tk system taking
over your application) please post here; thanks.
--
Bart
superpollo
superpollo
also, esr seems to know that:
"Libraries to provide language bindings to Tk are generally available
for C and C++."
http://www.catb.org/~esr/writings/taouu/html/ch03s03.html
who knows.
bye
superpollo
Nobody
> If you find out how to use Tk stuff from C (without the Tk system taking
> over your application) please post here; thanks.
If you don't want to write an "enhanced wish", you need to clone
Tk_MainEx(), but omit the Tk_MainLoop() call. Tk_MainLoop() itself is
just:
void
Tk_MainLoop()
{
while (Tk_GetNumMainWindows() > 0) {
Tcl_DoOneEvent(0);
}
}
but there isn't a specific "initialise Tk without entering the main loop"
function.
superpollo
still...
i would like to see a minimal but interactive iso C program with tk
widgets that compiles and runs on at least two popular platforms (say
gcc on linux and mingw on win32).
bye
Nobody
>>>If you find out how to use Tk stuff from C (without the Tk system taking
>>>over your application) please post here; thanks.
>>
>> If you don't want to write an "enhanced wish", you need to clone
>> Tk_MainEx(), but omit the Tk_MainLoop() call. Tk_MainLoop() itself is
>> just:
[snip]
>> but there isn't a specific "initialise Tk without entering the main
>> loop" function.
>
> still...
>
> i would like to see a minimal but interactive iso C program with tk
> widgets that compiles and runs on at least two popular platforms (say
> gcc on linux and mingw on win32).
Well, wish itself fits that specification. Any trivial program is going to
be most logically implemented as an enhanced wish; you would have to put
some thought into contriving an example where letting Tk's main loop run
would cause significant problems.
Beyond that, it's normal for GUI toolkits to "take over" the application;
Tk isn't alone in this regard. Almost any non-trivial use of the toolkit
requires letting it process pending events.