Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #126371 > unrolled thread
| Started by | shinobi@f153.n1.z21.fsxnet (shinobi) |
|---|---|
| First post | 2018-02-07 11:14 +1200 |
| Last post | 2018-02-08 19:58 +0000 |
| Articles | 20 on this page of 67 — 16 participants |
Back to article view | Back to comp.lang.c
Good C compiler for WIN64 shinobi@f153.n1.z21.fsxnet (shinobi) - 2018-02-07 11:14 +1200
Re: Good C compiler for WIN64 David Brown <david.brown@hesbynett.no> - 2018-02-07 14:04 +0100
Re: Good C compiler for WIN64 Keith Thompson <kst-u@mib.org> - 2018-02-07 09:52 -0800
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-07 18:24 +0000
Re: Good C compiler for WIN64 shinobi@f153.n1.z21.fsxnet (shinobi) - 2018-02-07 16:10 +1200
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-07 13:48 +0000
Re: Good C compiler for WIN64 Robert Wessel <robertwessel2@yahoo.com> - 2018-02-08 01:41 -0600
Re: Good C compiler for WIN64 Robert Wessel <robertwessel2@yahoo.com> - 2018-02-08 01:44 -0600
Re: Good C compiler for WIN64 Noob <root@127.0.0.1> - 2018-02-07 21:18 +0100
Re: Good C compiler for WIN64 shinobi@f153.n1.z21.fsxnet (shinobi) - 2018-02-08 08:22 +1200
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-08 10:40 +0000
Re: Good C compiler for WIN64 "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-02-08 00:06 +0800
Re: Good C compiler for WIN64 shinobi@f153.n1.z21.fsxnet (shinobi) - 2018-02-08 08:21 +1200
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-08 10:36 +0000
Re: Good C compiler for WIN64 already5chosen@yahoo.com - 2018-02-08 03:49 -0800
Re: Good C compiler for WIN64 Robbie Hatley <loneSNIPwolf@wellCUT.com> - 2018-02-08 03:22 -0800
Re: Good C compiler for WIN64 already5chosen@yahoo.com - 2018-02-08 04:05 -0800
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-08 12:32 +0000
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-08 12:40 +0000
Re: Good C compiler for WIN64 David Brown <david.brown@hesbynett.no> - 2018-02-08 14:36 +0100
Re: Good C compiler for WIN64 Robbie Hatley <loneSNIPwolf@wellCUT.com> - 2018-02-08 09:47 -0800
Re: Good C compiler for WIN64 already5chosen@yahoo.com - 2018-02-08 10:33 -0800
Re: Good C compiler for WIN64 David Brown <david.brown@hesbynett.no> - 2018-02-09 10:33 +0100
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-09 10:48 +0000
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-09 11:18 +0000
Re: Good C compiler for WIN64 David Brown <david.brown@hesbynett.no> - 2018-02-09 15:24 +0100
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-10 12:56 +0000
Re: Good C compiler for WIN64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-10 15:44 +0000
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-10 16:13 +0000
Re: Good C compiler for WIN64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-10 17:36 +0000
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-10 18:15 +0000
Re: Good C compiler for WIN64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-10 18:27 +0000
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-10 18:42 +0000
Re: Good C compiler for WIN64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-10 20:03 +0000
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-10 20:23 +0000
Re: Good C compiler for WIN64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-10 20:58 +0000
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-10 21:13 +0000
Re: Good C compiler for WIN64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-10 21:40 +0000
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-10 22:22 +0000
Re: Good C compiler for WIN64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-10 23:39 +0000
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-11 01:07 +0000
Re: Good C compiler for WIN64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-11 01:23 +0000
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-11 01:38 +0000
Re: Good C compiler for WIN64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-11 01:42 +0000
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-11 10:58 +0000
Re: Good C compiler for WIN64 Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-02-11 03:17 -0800
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-11 11:33 +0000
Re: Good C compiler for WIN64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-11 14:21 +0000
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-11 15:05 +0000
Re: Good C compiler for WIN64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-11 17:08 +0000
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-12 22:32 +0000
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-10 18:26 +0000
Re: Good C compiler for WIN64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-10 20:02 +0000
Re: Good C compiler for WIN64 Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-10 14:45 +0000
Re: Good C compiler for WIN64 GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-10 16:42 +0100
Re: Good C compiler for WIN64 Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-11 08:16 +0000
Re: Good C compiler for WIN64 GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 13:48 +0100
Re: Good C compiler for WIN64 Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-11 15:42 +0000
Re: Good C compiler for WIN64 GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-02-11 18:44 +0100
Re: Good C compiler for WIN64 Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-02-12 15:39 +0000
Re: Good C compiler for WIN64 David Brown <david.brown@hesbynett.no> - 2018-02-11 16:26 +0100
Re: Good C compiler for WIN64 Ian Collins <ian-news@hotmail.com> - 2018-02-10 09:50 +1300
Re: Good C compiler for WIN64 Thiago Adams <thiago.adams@gmail.com> - 2018-02-08 12:21 -0800
Re: Good C compiler for WIN64 bartc <bc@freeuk.com> - 2018-02-08 22:52 +0000
Re: Good C compiler for WIN64 Thiago Adams <thiago.adams@gmail.com> - 2018-02-09 10:01 -0800
Re: Good C compiler for WIN64 jacobnavia <jacob@jacob.remcomp.fr> - 2018-02-08 20:16 +0100
Re: Good C compiler for WIN64 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-08 19:58 +0000
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | Robbie Hatley <loneSNIPwolf@wellCUT.com> |
|---|---|
| Date | 2018-02-08 09:47 -0800 |
| Message-ID | <Y5udnaNXkqzjEOHHnZ2dnUU7_83NnZ2d@giganews.com> |
| In reply to | #126436 |
(Drat, hit "reply" instead of "followup" again. Let's try that again.) On 2/8/2018 5:36 AM, David Brown wrote: > Mingw (including tdm) has less complete Posix emulation, > but is far simpler and easier to work with According to Wikipedia, MinGW hasn't been updated since 2013. Someone did a fork recently called "MinGW-w64", but it's by a different author. "MSYS2" is, according to my research, a rehash of Cygwin. Cygwin's Linuxification of Windows suits me fine. That, and I already have it installed and running. And, I love it's enormous collection of optional elements, and frequent updates, sometimes daily. (Sometimes twice daily.) But MinGW-w64 and MSYS2 do sound intriguing. I'm tempted to install both just to learn more about them. Especially if one or the other is set-up to create Windows GUI apps. Currently I'm using National Instruments "CVI/LabWindows" for most GUI apps I create (which isn't often; must stuff I do is better done via CLI). But CVI does have its limitations. I also sometimes use AutoIt to create Windows GUI apps. And it's free. Go to web site autoitscript.com for more info. I also used to have Bloodshed's "Dev C++" IDE installed. I need to reinstall that. (Got wiped out in last HD crash.) It can use any GCC type compiler (Cygwin, MinGW-w64, MSYS2, etc) as its compiler. It also has a MinGW-based C & C++ compiler built-in. And I used to have a very-old installation of Microsoft Visual Studio, but I can't afford to spend thousands of $ on the latest version of that. (I might re-install the old version, though, just to keep from completely forgetting the Win32 API.) So there are lots of options out there, many of them free. -- Cheers, Robbie Hatley Midway City, CA, USA perl -E 'say "\154o\156e\167o\154f\100w\145ll\56c\157m";' http://www.well.com/user/lonewolf/ https://www.facebook.com/robbie.hatley
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2018-02-08 10:33 -0800 |
| Message-ID | <2d52f009-4ae2-485b-afc8-a3c9c0842b45@googlegroups.com> |
| In reply to | #126445 |
On Thursday, February 8, 2018 at 7:49:02 PM UTC+2, Robbie Hatley wrote: > (Drat, hit "reply" instead of "followup" again. Let's try that again.) > > On 2/8/2018 5:36 AM, David Brown wrote: > > > Mingw (including tdm) has less complete Posix emulation, > > but is far simpler and easier to work with > > According to Wikipedia, MinGW hasn't been updated since 2013. Yes, according to my understanding it's close to Abandonware status. Probably, still useful for 32-bit Windows. > > Someone did a fork recently called "MinGW-w64", but it's by a different > author. > > "MSYS2" is, according to my research, a rehash of Cygwin. Sort of. But it is better integrated with "native" Windows. At least, better than cygwin of old. I didn't try the more recent cygwins. The most recent that I have is the one that came with Nios2 SDK 16.1, so probably more than 2 years old, gcc under MSYS2 produces native win32 apps by default. IIRC, it's possible to generate native WIn32 apps from cygwin, but it's not a default. As David said, the main cost is reduced source-code compatibility with Linux. > > Cygwin's Linuxification of Windows suits me fine. That, and I already > have it installed and running. And, I love it's enormous collection of > optional elements, and frequent updates, sometimes daily. (Sometimes > twice daily.) MSYS2 does not things upgrade proactively. I prefer it that way. > > But MinGW-w64 and MSYS2 do sound intriguing. They are the same thing, more or less. > I'm tempted to install both > just to learn more about them. Especially if one or the other is set-up > to create Windows GUI apps. > > Currently I'm using National Instruments "CVI/LabWindows" for most GUI > apps I create (which isn't often; must stuff I do is better done via CLI). > But CVI does have its limitations. > > I also sometimes use AutoIt to create Windows GUI apps. And it's free. > Go to web site autoitscript.com for more info. > > I also used to have Bloodshed's "Dev C++" IDE installed. I need to > reinstall that. (Got wiped out in last HD crash.) It can use any GCC > type compiler (Cygwin, MinGW-w64, MSYS2, etc) as its compiler. It also > has a MinGW-based C & C++ compiler built-in. > > And I used to have a very-old installation of Microsoft Visual Studio, > but I can't afford to spend thousands of $ on the latest version of that. > (I might re-install the old version, though, just to keep from completely > forgetting the Win32 API.) > I never tried to develop a GUI in C or C++ on the free version of Visual Studio, but I think that it is possible since 2008. Could be wrong about it. As to command line, that was possible since very first free version, i.e. close to 13 years. As to thousands of $, I think throughout the years a price of stand-alone license for "a Standard Edition" under different names (the current name is "Professional") never was more $500 (like it is now) and more typically $300. But Free "community edition" is likely fine for your needs. But be prepared for a HUGE download. > So there are lots of options out there, many of them free. > > > -- > Cheers, > Robbie Hatley > Midway City, CA, USA > perl -E 'say "\154o\156e\167o\154f\100w\145ll\56c\157m";' > http://www.well.com/user/lonewolf/ > https://www.facebook.com/robbie.hatley
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-02-09 10:33 +0100 |
| Message-ID | <p5jpu3$anu$1@dont-email.me> |
| In reply to | #126445 |
On 08/02/18 18:47, Robbie Hatley wrote: > > (Drat, hit "reply" instead of "followup" again. Let's try that again.) (I was wondering about that - I saw the email before the Usenet posting. I'm sure we've all done it on occasion.) > > On 2/8/2018 5:36 AM, David Brown wrote: > >> Mingw (including tdm) has less complete Posix emulation, >> but is far simpler and easier to work with > > According to Wikipedia, MinGW hasn't been updated since 2013. > > Someone did a fork recently called "MinGW-w64", but it's by a different > author. Yes. I was using "mingw" generically here - my first reply to the OP specified mingw-w64. The naming here is a bit confusing (people could easily think that one is for 32-bit windows, the other for 64-bit), perhaps, but Wikipedia/Google are very helpful. A key point of difference is that in the original mingw the aim was a port of the compiler, and it used MS's C libraries. That meant abysmal C99 support. Mingw-w64 uses a proper C library (I can't remember which one off-hand), thus giving much more complete modern C support. And it can generate 32-bit and 64-bit code. tdm is a packaging of mingw or mingw-w64 toolchains, aimed at being as easy as possible to install. It seems to be a little out of date, but the C world doesn't change /that/ quickly. > > "MSYS2" is, according to my research, a rehash of Cygwin. It is based on a similar principle. But it is compiled using the mingw-w64 toolchain rather than the cygwin toolchain. That means all the ports have a much lighter Posix interface layer. You get the same tools - mv, cp, cat, grep, awk, sed, etc. Cygwin has layers to make the filesystem appear Posix-style with a single root, while mingw uses Windows-style file names (or with forward slashes if you prefer). Cygwin provides "fork", at great expense, while mingw only has "vfork". Cygwin generated programs require a fair number of dll's, and get really upset when you have more than one cygwin1.dll in use at a time - mingw generated programs have a lot more done with static linking because the interface code is small enough. All in all, cygwin gives you the closest to Posix on Windows, but is slow and always feels a bit alien. Mingw and msys (or the newer mingw-w64 and msys2) are more efficient and integrate far better in the windows world. It is a choice - for me, it is always mingw-w64/msys2 first, and cygwin if it is unavoidable. (There are also major licensing differences, if you are interested in that aspect.) > > Cygwin's Linuxification of Windows suits me fine. That, and I already > have it installed and running. And, I love it's enormous collection of > optional elements, and frequent updates, sometimes daily. (Sometimes > twice daily.) > > But MinGW-w64 and MSYS2 do sound intriguing. I'm tempted to install both > just to learn more about them. Especially if one or the other is set-up > to create Windows GUI apps. Give them a try - you have nothing to lose but your time and effort! I think trying to write Windows gui apps in C is a path to insanity - there are much better languages for the job. mingw (all variants) support C++, which many think is better for guis. (mingw-64 will give you newer gcc, as C++ /does/ change quickly.) Popular toolkits are wxWidgets and QT, but there are many, many others with different balances of features and complexity. Head to comp.lang.c++ for some info about a new toolkit written by someone there, if that's your cup of tea. Personally, I write most gui stuff with Python these days. I'm a fan of looking for the right language for the job, rather than trying to do everything with the one language. > > Currently I'm using National Instruments "CVI/LabWindows" for most GUI > apps I create (which isn't often; must stuff I do is better done via CLI). > But CVI does have its limitations. > > I also sometimes use AutoIt to create Windows GUI apps. And it's free. > Go to web site autoitscript.com for more info. > > I also used to have Bloodshed's "Dev C++" IDE installed. I need to > reinstall that. (Got wiped out in last HD crash.) It can use any GCC > type compiler (Cygwin, MinGW-w64, MSYS2, etc) as its compiler. It also > has a MinGW-based C & C++ compiler built-in. > > And I used to have a very-old installation of Microsoft Visual Studio, > but I can't afford to spend thousands of $ on the latest version of that. > (I might re-install the old version, though, just to keep from completely > forgetting the Win32 API.) > > So there are lots of options out there, many of them free. > Yes.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-09 10:48 +0000 |
| Message-ID | <00ffC.556298$5k2.137820@fx12.am4> |
| In reply to | #126469 |
> tdm is a packaging of mingw or mingw-w64 toolchains, aimed at being as
> easy as possible to install.
That suggests that installing mingw wasn't quite as simple as you
suggested. Otherwise why go to the bother of creating tdm?
It seems to be the aim of these tools from Linux to be as obscure as
possible.
I'm still, after several years, unsure of what mingw is actually meant
to be. Apparently it's a minimalistic toolchain, which leaves one
wondering what a non-minimalist one might look like.
So it includes a C compiler, but is it meant to also include the
necessary include files? Assembler? Linker? Import libraries? Actual
Libraries?
What are cygwin and Msys and Msys2, and why are they considered so
important to some?
Even the simpler tdm includes a directory called:
./x86_64-w64-mingw32
Which surely wasn't chosen to be easy to type or to remember. "64"
occurs twice. It uses both "_" and "-" separators. "w" occurs twice. It
has "32" even though both 32- and 64-bit targets are supported.
This is why smaller, self-contained products such as Pelles C, lccwin,
the old DMC, and also Tiny C are important. Created by individuals, it
gives them a human touch.
> Personally, I write most gui stuff with Python these days.
Which library? There seem to be loads.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-09 11:18 +0000 |
| Message-ID | <OrffC.642747$bH7.563945@fx38.am4> |
| In reply to | #126470 |
On 09/02/2018 10:48, bartc wrote:
> I'm still, after several years, unsure of what mingw is actually meant
> to be. Apparently it's a minimalistic toolchain, which leaves one
> wondering what a non-minimalist one might look like.
>
> So it includes a C compiler, but is it meant to also include the
> necessary include files? Assembler? Linker? Import libraries? Actual
> Libraries?
From the wikipedia article on mingw:
"Most languages supported by GCC are supported on the MinGW port as
well. These include C, C++, Objective-C, Objective-C++, Fortran and Ada.
The GCC runtime libraries are used (libstdc++ for C++, libgfortran for
Fortran, etc.)."
Which makes it even more confusing. So mingw isn't actually anything
specifically to do with a C compiler. It might include one, or it might
not. Or maybe it includes all of those compilers.
That makes the case for those separate products that are C compilers and
nothing else, even more strongly.
------------------------
(Here's the entire toolchain my C compiler uses; at moment it's four
files, not the one file that I would prefer:
mcc.exe 234KB Compile .c to .a64 asm source file
mxa.exe 93KB Assemble .a64 to .obj
link.exe 1420KB Link .obj and .dll files to .exe
mcclib.a64 2KB Support library
link.exe is renamed from ld.exe, taken from a FreeBasic distribution,
which itself took it from gcc/mingw/binutils/linux or whatever the hell
it is. It's the biggest program even though it has the simplest task.
Those four files are sufficient to turn the .c and .h files of a project
like Lua into a .exe file.
/This/ is rather more minimalistic than mingw. Even more so when I get
it down to one file!)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-02-09 15:24 +0100 |
| Message-ID | <p5kavf$rh$1@dont-email.me> |
| In reply to | #126470 |
On 09/02/18 11:48, bartc wrote: > >> tdm is a packaging of mingw or mingw-w64 toolchains, aimed at being as >> easy as possible to install. > > That suggests that installing mingw wasn't quite as simple as you > suggested. Otherwise why go to the bother of creating tdm? The world is not black and white - nor is installation divided into "mind-numbingly simple even for absolute newbies" and "impossibly difficult unless you are a Linux geek". It is perfectly reasonable to say that installing mingw-w64 is straightforward and not difficult, while also saying that installing tdm is probably even easier. > > It seems to be the aim of these tools from Linux to be as obscure as > possible. Yes, I am sure that is their aim. The folks being these projects (which are not, as you well know, "tools from Linux") came up with a cunning business plan: 1. Lets make some software that is as difficult as possible to use. 2. ? 3. Profit ! > > I'm still, after several years, unsure of what mingw is actually meant > to be. Apparently it's a minimalistic toolchain, which leaves one > wondering what a non-minimalist one might look like. You are unsure of a great deal of things in the C world. Informing you doesn't see to help, so I'm not going to bother. Try google. > > So it includes a C compiler, but is it meant to also include the > necessary include files? Assembler? Linker? Import libraries? Actual > Libraries? Yes - it is a toolchain. > > What are cygwin and Msys and Msys2, and why are they considered so > important to some? I believe that has already been explained. > > Even the simpler tdm includes a directory called: > > ./x86_64-w64-mingw32 > > Which surely wasn't chosen to be easy to type or to remember. "64" > occurs twice. It uses both "_" and "-" separators. "w" occurs twice. It > has "32" even though both 32- and 64-bit targets are supported. "x86_64" is the target processor architecture, "w64" is the "vendor" (abbreviation for mingw-w64 in this case), and "mingw32" is the "os" (i.e., windows). So that directory covers files needed for compiling for windows files with mingw-w64 toolchain, targeting 64-bit x86 processors. When you are used to simple C compilers that are always native (identical host and target), this kind of flexibility may seem unnecessary. But remember, gcc is /not/ a simple limited native C compiler. mingw-w64 tools and libraries are available for all sorts of systems - if you want, you can use it on an ARM-based Raspberry Pi running Linux to cross-compile for x86 (32-bit or 64-bit) Windows. (Installation is /really/ scary - "apt-get install mingw-w64"). And these name "triplets" are used in general for gcc for any mix of host and target systems - the one I use most has "arm-none-eabi" as its triplet. > > This is why smaller, self-contained products such as Pelles C, lccwin, > the old DMC, and also Tiny C are important. Created by individuals, it > gives them a human touch. I couldn't care less about a "human touch" in a compiler or its associated libraries, headers, utilities, etc. I like a "human touch" in the support, and being able to talk to people involved in the development or support. I don't want to be "friends" with my compiler, any more than I want to be friends with my car - they are tools. I want a "human touch" from the folks selling me a car, or the repairing it - not from the car itself. I want to understand how to /use/ my car, and how to get the best out of it - I am not particularly interested in how it works, or how many different parts there are under the bonnet. > >> Personally, I write most gui stuff with Python these days. > > Which library? There seem to be loads. > Mostly wxPython, but I've used Tkinter a little. I don't do a great deal of gui programming.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-10 12:56 +0000 |
| Message-ID | <3_BfC.534010$dh6.506913@fx42.am4> |
| In reply to | #126478 |
On 09/02/2018 14:24, David Brown wrote: > On 09/02/18 11:48, bartc wrote: >> I'm still, after several years, unsure of what mingw is actually meant >> to be. Apparently it's a minimalistic toolchain, which leaves one >> wondering what a non-minimalist one might look like. > > You are unsure of a great deal of things in the C world. You are implying then that MingW is to do with C. But if you do google Mingw, it's something to do with GNU. Actually every link seems to say something different or adds something else. Informing you > doesn't see to help, so I'm not going to bother. Try google. And this is the point. In the non-Unix world, everything is much more clear cut. In the Unix world, everything is mixed up: the OS, include files, languages, compilers, libraries etc are so intertwined that you never know which is part of which. In Windows, Pelles C is a C compiler that comes with include files, libraries, a C compiler and linker. The same with lccwin. The same with DMC. The same with Tiny C. So far, everyone understands exactly what these products are, what their scope is, and what they can do (some might come with an optional IDE). The dividing line between the OS and these products is also very clear. Now introduce MingW. And Msys and Msys2 and Cygwin and POSIX and all this other stuff. Now everything is a sprawling mess. Mingw is still separate from Windows itself, but is it separate from the Unix-like systems from which it was ported? It would be ironic if there were stronger links between mingw and Unix than between mingw and Windows! Could you explain to a complete beginner what MingW is all about, what it includes and how it differs from those dedicated C compiler suites? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-10 15:44 +0000 |
| Message-ID | <87mv0gonlw.fsf@bsb.me.uk> |
| In reply to | #126513 |
bartc <bc@freeuk.com> writes: <snip> > In Windows, Pelles C is a C compiler that comes with include files, > libraries, a C compiler and linker. > > The same with lccwin. > > The same with DMC. > > The same with Tiny C. > > So far, everyone understands exactly what these products are, what > their scope is, and what they can do (some might come with an optional > IDE). The dividing line between the OS and these products is also very > clear. > > Now introduce MingW. And Msys and Msys2 and Cygwin and POSIX and all > this other stuff. Now everything is a sprawling mess. So don't use it. I don't see what the problem is. And it's all open source, so you could help the world (if you think there is areal need) by packaging up as much or as little of this stuff as you think is needed. If you think it won't ever meet your needs, than just leave it alone. What I don't get is the complaining about stuff. How does it hurt you that someone packaged these things up in a way that you don't like? Re-do it or walk away. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-10 16:13 +0000 |
| Message-ID | <FSEfC.498781$1t7.88805@fx03.am4> |
| In reply to | #126518 |
On 10/02/2018 15:44, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: > <snip> >> In Windows, Pelles C is a C compiler that comes with include files, >> libraries, a C compiler and linker. >> >> The same with lccwin. >> >> The same with DMC. >> >> The same with Tiny C. >> >> So far, everyone understands exactly what these products are, what >> their scope is, and what they can do (some might come with an optional >> IDE). The dividing line between the OS and these products is also very >> clear. >> >> Now introduce MingW. And Msys and Msys2 and Cygwin and POSIX and all >> this other stuff. Now everything is a sprawling mess. > > So don't use it. I don't see what the problem is. The problem is people saying it's simple when it isn't. You can deal with necessary complexity but tidy packaging and clear documentation, but in my dealings with Linux, gcc, mingw and anything else connected with it, that has not been the case. And it's all open > source, Seriously? Just the source bundle of gcc is nearly 100,000 files. And I have no idea how many relate to Mingw; neither 'all' nor 'none' would be a surprising answer. I don't know about you, but to me, 100,000 files (I think nearly half were .c and .h files), is a big project. I wouldn't have a clue where to start even building it as it is. so you could help the world (if you think there is areal need) > by packaging up as much or as little of this stuff as you think is > needed. If you think it won't ever meet your needs, than just leave it > alone. > > What I don't get is the complaining about stuff. How does it hurt you > that someone packaged these things up in a way that you don't like? > Re-do it or walk away. I am actually re-doing parts, but as completely different implementations. My C compiler was never a serious product, but is usable (it can act as a drop-in replacement for gcc for most of my projects) and shows how tidily such a program /could/ be packaged. My x64 assembler has now completely replaced my use of Nasm. And it looks like I will also have to replace the linker as that component is now out of place. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-10 17:36 +0000 |
| Message-ID | <87h8qon3w5.fsf@bsb.me.uk> |
| In reply to | #126520 |
bartc <bc@freeuk.com> writes: > On 10/02/2018 15:44, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: >> <snip> >>> In Windows, Pelles C is a C compiler that comes with include files, >>> libraries, a C compiler and linker. >>> >>> The same with lccwin. >>> >>> The same with DMC. >>> >>> The same with Tiny C. >>> >>> So far, everyone understands exactly what these products are, what >>> their scope is, and what they can do (some might come with an optional >>> IDE). The dividing line between the OS and these products is also very >>> clear. >>> >>> Now introduce MingW. And Msys and Msys2 and Cygwin and POSIX and all >>> this other stuff. Now everything is a sprawling mess. >> >> So don't use it. I don't see what the problem is. > > The problem is people saying it's simple when it isn't. OK. Maybe that's just a difference over the word. Does it really matter now that you'd said you don't consider it simple? Is there any more than can be useful said? >> And it's all open source, > > Seriously? Yes, that's a true fact as far as I know. > Just the source bundle of gcc is nearly 100,000 files. And I have no > idea how many relate to Mingw; neither 'all' nor 'none' would be a > surprising answer. > > I don't know about you, but to me, 100,000 files (I think nearly half > were .c and .h files), is a big project. I wouldn't have a clue where > to start even building it as it is. OK, so you can't re-package it how you want (and I don't think anyone said this part is simple). >> What I don't get is the complaining about stuff. How does it hurt you >> that someone packaged these things up in a way that you don't like? >> Re-do it or walk away. > > I am actually re-doing parts, but as completely different > implementations. Great. Will it be free and/or open source too? (I think I would have spent the time helping an existing project like tcc to be more to my liking. Many of the changes would surely benefit the project as whole. Maybe there was nothing you could take as a starting point.) > My C compiler was never a serious product, but is usable (it can act > as a drop-in replacement for gcc for most of my projects) and shows > how tidily such a program /could/ be packaged. Did anyone doubt that? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-10 18:15 +0000 |
| Message-ID | <vEGfC.692126$fg4.311008@fx08.am4> |
| In reply to | #126522 |
On 10/02/2018 17:36, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: >> I am actually re-doing parts, but as completely different >> implementations. > > Great. Will it be free and/or open source too? By parts I means the main components such as C compiler, assembler and linker, as programs unrelated to mingw, and for specific targets. They will most likely be available as single file C amalgamations and as .exe files. I don't know about the multi-file true sources; I'd need a tidy way of presenting them. > (I think I would have spent the time helping an existing project like > tcc to be more to my liking. Many of the changes would surely benefit > the project as whole. Maybe there was nothing you could take as a > starting point.) This [my compiler] was a rival product to Tiny C. It also wasn't written in C and was specifically intended to be written from scratch and be 100% my own work. It will also (when I replace the temporary code generator) generate faster code than Tiny C; that couldn't really be done by just tweaking the sources. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-10 18:27 +0000 |
| Message-ID | <876074n1iz.fsf@bsb.me.uk> |
| In reply to | #126524 |
bartc <bc@freeuk.com> writes: > On 10/02/2018 17:36, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: > >>> I am actually re-doing parts, but as completely different >>> implementations. >> >> Great. Will it be free and/or open source too? > > By parts I means the main components such as C compiler, assembler and > linker, as programs unrelated to mingw, and for specific targets. > > They will most likely be available as single file C amalgamations and > as .exe files. I don't know about the multi-file true sources; I'd > need a tidy way of presenting them. I think you may have misunderstood the question (because I see nothing that could be an answer) but then neither can I see what might have been misunderstood. I don't think it merits more posts though. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-10 18:42 +0000 |
| Message-ID | <72HfC.500959$1t7.49309@fx03.am4> |
| In reply to | #126526 |
On 10/02/2018 18:27, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: > >> On 10/02/2018 17:36, Ben Bacarisse wrote: >>> bartc <bc@freeuk.com> writes: >> >>>> I am actually re-doing parts, but as completely different >>>> implementations. >>> >>> Great. Will it be free and/or open source too? >> >> By parts I means the main components such as C compiler, assembler and >> linker, as programs unrelated to mingw, and for specific targets. >> >> They will most likely be available as single file C amalgamations and >> as .exe files. I don't know about the multi-file true sources; I'd >> need a tidy way of presenting them. > > I think you may have misunderstood the question (because I see nothing > that could be an answer) but then neither can I see what might have been > misunderstood. I don't think it merits more posts though. OK, you thought I was actually doing something with bits of Mingw sources. No, I mean that I am independently writing separate programs (compilers etc) that do some of the same tasks. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-10 20:03 +0000 |
| Message-ID | <87tvuolihq.fsf@bsb.me.uk> |
| In reply to | #126529 |
bartc <bc@freeuk.com> writes: > On 10/02/2018 18:27, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: >> >>> On 10/02/2018 17:36, Ben Bacarisse wrote: >>>> bartc <bc@freeuk.com> writes: >>> >>>>> I am actually re-doing parts, but as completely different >>>>> implementations. >>>> >>>> Great. Will it be free and/or open source too? >>> >>> By parts I means the main components such as C compiler, assembler and >>> linker, as programs unrelated to mingw, and for specific targets. >>> >>> They will most likely be available as single file C amalgamations and >>> as .exe files. I don't know about the multi-file true sources; I'd >>> need a tidy way of presenting them. >> >> I think you may have misunderstood the question (because I see nothing >> that could be an answer) but then neither can I see what might have been >> misunderstood. I don't think it merits more posts though. !! > OK, you thought I was actually doing something with bits of Mingw > sources. No. > No, I mean that I am independently writing separate programs > (compilers etc) that do some of the same tasks. I understood that. I was simply asking if those programs would also be open source. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-10 20:23 +0000 |
| Message-ID | <gxIfC.163695$bm7.107211@fx01.am4> |
| In reply to | #126532 |
On 10/02/2018 20:03, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: >> No, I mean that I am independently writing separate programs >> (compilers etc) that do some of the same tasks. > > I understood that. I was simply asking if those programs would also be > open source. I thought I'd answered that: Yes. No. Probably. There's a slight complication. I can easily supply C representations of the sources (I think all these programs will be compiled code to get the best speed as that is a feature), but those will not the true sources. That C code is largely readable and people can do what they like with the code. The problem is that the true sources are in a non-standard language requiring special tools to build, and that people will not be familiar with. I can supply sources of the those tools, but they are also in the same language. The real intent however is to show what is possible when working at a small scale. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-10 20:58 +0000 |
| Message-ID | <87o9kwlfyx.fsf@bsb.me.uk> |
| In reply to | #126534 |
bartc <bc@freeuk.com> writes: > On 10/02/2018 20:03, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: > >>> No, I mean that I am independently writing separate programs >>> (compilers etc) that do some of the same tasks. >> >> I understood that. I was simply asking if those programs would also be >> open source. > > I thought I'd answered that: Yes. No. Probably. > > There's a slight complication. I can easily supply C representations > of the sources (I think all these programs will be compiled code to > get the best speed as that is a feature), but those will not the true > sources. That's an interesting case. In general idea of open source is that the real sources be published. If it's some derived code, the I don't think that would be considered open source. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-10 21:13 +0000 |
| Message-ID | <LfJfC.531557$wk7.464145@fx28.am4> |
| In reply to | #126538 |
On 10/02/2018 20:58, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: > >> On 10/02/2018 20:03, Ben Bacarisse wrote: >>> bartc <bc@freeuk.com> writes: >> >>>> No, I mean that I am independently writing separate programs >>>> (compilers etc) that do some of the same tasks. >>> >>> I understood that. I was simply asking if those programs would also be >>> open source. >> >> I thought I'd answered that: Yes. No. Probably. >> >> There's a slight complication. I can easily supply C representations >> of the sources (I think all these programs will be compiled code to >> get the best speed as that is a feature), but those will not the true >> sources. > > That's an interesting case. In general idea of open source is that the > real sources be published. If it's some derived code, the I don't > think that would be considered open source. I've seen more than a few open source projects where you can't compile the source code unless you first run some scripts to generate essential headers or other chunks of the C source. The source code for those tools is not usually provided. You can't compile the C as it comes. When I provide C code however, it can be compiled as is; it just requires a C compiler, not unreasonably. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-10 21:40 +0000 |
| Message-ID | <87inb4le0u.fsf@bsb.me.uk> |
| In reply to | #126539 |
bartc <bc@freeuk.com> writes: > On 10/02/2018 20:58, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: >> >>> On 10/02/2018 20:03, Ben Bacarisse wrote: >>>> bartc <bc@freeuk.com> writes: >>> >>>>> No, I mean that I am independently writing separate programs >>>>> (compilers etc) that do some of the same tasks. >>>> >>>> I understood that. I was simply asking if those programs would also be >>>> open source. >>> >>> I thought I'd answered that: Yes. No. Probably. >>> >>> There's a slight complication. I can easily supply C representations >>> of the sources (I think all these programs will be compiled code to >>> get the best speed as that is a feature), but those will not the true >>> sources. >> >> That's an interesting case. In general idea of open source is that the >> real sources be published. If it's some derived code, the I don't >> think that would be considered open source. > > I've seen more than a few open source projects where you can't compile > the source code unless you first run some scripts to generate > essential headers or other chunks of the C source. The source code for > those tools is not usually provided. I would hesitate to call them open-source projects then (unless it was simply an oversight or user error, of course). I can't think of any reason to do this deliberately. Are you sure it was not simply and mistake? Are there any you can remember? > When I provide C code however, it can be compiled as is; it just > requires a C compiler, not unreasonably. As I say, that would probably not be considered open source, but does it matter to you? I was simply wondering what your plans were. [The OSI definition of open source includes: "The source code must be the preferred form in which a programmer would modify the program." and "Intermediate forms such as the output of a preprocessor or translator are not allowed."] -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-02-10 22:22 +0000 |
| Message-ID | <DgKfC.369793$R83.213048@fx45.am4> |
| In reply to | #126544 |
On 10/02/2018 21:40, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: >> I've seen more than a few open source projects where you can't compile >> the source code unless you first run some scripts to generate >> essential headers or other chunks of the C source. The source code for >> those tools is not usually provided. > > I would hesitate to call them open-source projects then (unless it was > simply an oversight or user error, of course). I can't think of any > reason to do this deliberately. Are you sure it was not simply and > mistake? Are there any you can remember? Most of the them I think! A simple example is Tiny C. This won't compile as config.h is missing. Some configure script has to generate it. But it's not very complicated, it just needs to contain: #define TCC_VERSION "0.9.26" Still, you can't do anything until you've figured this out. LuaJIT also needs to first run programs to generate tables of data in C source format. This is the primary reason why I have trouble compiling open source projects. Even when the C compiles directly, parts of it may be generated via macros. If that's done simply, then it's a benefit: you maintain the macros. But it can also be done so cryptically and cleverly that it might as well be closed source (LuaJIT is like this). >> When I provide C code however, it can be compiled as is; it just >> requires a C compiler, not unreasonably. > > As I say, that would probably not be considered open source, but does it > matter to you? I was simply wondering what your plans were. It's not a big deal. I can provide true open source (but I need to remove all the untidy commented-out bits of code left over from hundreds of debugging runs), the tools need to build it, and some docs on the language, if there is a demand. I'm not planning on making money out of it. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-02-10 23:39 +0000 |
| Message-ID | <87d11cl8ic.fsf@bsb.me.uk> |
| In reply to | #126545 |
bartc <bc@freeuk.com> writes: > On 10/02/2018 21:40, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: > >>> I've seen more than a few open source projects where you can't compile >>> the source code unless you first run some scripts to generate >>> essential headers or other chunks of the C source. The source code for >>> those tools is not usually provided. >> >> I would hesitate to call them open-source projects then (unless it was >> simply an oversight or user error, of course). I can't think of any >> reason to do this deliberately. Are you sure it was not simply and >> mistake? Are there any you can remember? > > Most of the them I think! Must be a Windows thing or something particular to you maybe. Most of them work for me, but then almost everything on my system is automatically built form source packages (not by me, of course). > A simple example is Tiny C. This won't compile as config.h is > missing. Some configure script has to generate it. Yes, that's normal. Can you remember the package i.e. can you say where you got the source without the configure script (it can probably be easily fixed)? -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web