Maybe but the big problem is Google does WAY more than just look at traces. They employ sophisticated machine learning techniques to deduce data automatically from images, like automatically reading address bars on buildings.
They are not the only ones doing that. Mapillary is another that uses deep learning to process street-view images and extract important features.
Couldn't there be mobile apps we would run on our phones that relied on Google Maps for navigation but shared our travel experiences to Open Street Map. I wouldn't mind running an app like that for awhile.
You're in luck, there are multiple applications you can run on your phone what will help OpenStreetMap:
StreetComplete - Lets you fill in missing map details for things around you as you walk in the street.
Mapillary - Provides street-view images for OpenStreetMap.
OpenStreetCam - Provides street-view images for OpenStreetMap.
Regarding street-view, Mapillary is the more advanced of the two right now, at least in terms of coverage but also, as far as I can tell, with regards to what they can do with the images. Through deep learning they are now able to recognize street signs, traffic lights, urban furniture, generate 3D building models, etc. And you are allowed to use all this to contribute to OpenStreetMap.
OSM is what YOU make it, too bad you aren't contributing anything but complaints.
Yep. Don't ask what OpenStreetMap can do for you. Ask what you can do for OpenStreetMap.
It's no coincidence that all the places of interest to me are on OpenStreetMap.
The license allows for the data to be taken and incorporated in proprietary software.
I assume that GPL proponents would have a problem with that, otherwise I think they would argue for BSD or MIT style licenses instead.
Since the ODBL license terms are essentially the same as the LGPL I don't see why GPL proponents would have a problem with them: you can include LGPL code (resp. ODBL database) in proprietary software as long as you distribute the source for the LGPL code (resp. ODBL database) you used. The ODBL has an additional requirement: attribution.
You mean you have never put a new yearly registration sticker on your plate for the last 17 years?!?
Nope. And I didn't even change the license plate when I bought my car. Instead I just filed the paperwork so that the records show the car with this license plate is mine (and any fines go to me (but I didn't get to verify this part yet;-)). Oh, and in my country registration stickers went out of favor a couple of decades ago. And the stickers that indicate the car is insured and has been inspected for safety are behind the windshield. This also ensures miscreants cannot tamper with them. See? There's a solution to everything!
This sounds like a huge undertaking, and seems to be a smart move but it is daunting to think of the effort involved in changing a national alphabet. I am not sure I've ever heard of such an effort before, anyone else ??
Meh. Sounds much easier than switching the US to metric!
The OP, me, suggested putting one (1) "No Thru Traffic" sign on that one (1) street.
Then you, Ol Olsoc, replied talking about "Not a through street" signs. Now you, Ol Olsoc, have the gall to claim that the OP, me, is confusing "Not a through street" signs with "No Thru Traffic" ones! Not only that but you're trying to muddy things up by making ludricous assertions like claiming "So the solution is to put up signs at every intersection".
The only conclusion is that you, Ol Olsoc, are a troll whose only goal is to derail the discussion.
Thanks. Unfortunately that councilman's is as vague in this letter as in his previous declarations. It would have been nice to know what "new traffic signage" they tried, for how long, what reasons, if any, Waze and others gave to not take it into account, etc. As it is this councilman seems like all he wants is show the people he's trying to garner votes by flailing uselessly.
So your point is that in order to keep these speeders off my street, I have to break the law to leave my house. If every street in my neighborhood was illegal to use as a street to get somewhere else, we'd all be trapped.
[...]
One way in, one way out, no deviation allowed. The solution is worse than the problem.
Please relinquish your driver license. No through traffic signs have been in existence for decades and you should have learned all about them when getting your driving license. That you are so baffled by them means you have forgotten the basics and are no longer fit to drive.
So the solution is to put up signs at every intersection and implement bogus "Not a through street" zones.
The signs are not bogus if they are put up by the official traffic department. And the traffic department has no more reason to put them at every intersection than for any other sign.
LADOT has tried mitigation strategies such as new traffic signage, but this congestion
starts and ends with wayfinding technology.
Source? Neither the article nor any of the pages it points to mentions any traffic signage change. How long did they give Waze to update their map? 24 hours?
The solution is really simple. Mark the street as "No Thru Traffic" since that's essentially what he wants. Waze and others will update their maps accordingly. In OpenStreetMap it's just a matter of adding an "access=destination" attribute and I'm sure Waze, Google, Apple and others have similarly simple ways of representing this. They will then stop routing people through that street. The city does no even need to enforce the street sign since all they want to avoid is the excess traffic driven by the apps. Problem solved.
But only the city (or maybe some county/state department) has the authority to make that decision so he should work on it instead of making an ass of himself and wasting everyone else's time.
Who is designing that self-driving truck that can pick up trash cans automatically? That would be quite a feat.
In most countries trash cans are standardized which simplifies their collection quite a bit. I really don't see what would be so hard to automate about it. Not for tomorrow but in a 5 to 10 years. The only thing missing would be collecting overflowing refuse that's been left next to the trash can. But that means out of a team of three you would need at most one employee.
And don't point me to some youtube video of some self driving truck on a closed course picking up trash cans. That ain't reality.
It's called a prototype and is the step just before deployment. You're the one who's refusing to see that reality is changing.
What type of magical "automation" is coming that is going to massively replace jobs? People keep talking about "automation", but is there some magic technology coming that is going to automate out waiters and lawyers and doctors and trash collectors?
There are already restaurants in Japan with robots doing some of the tasks traditionally performed by waiters. Sure those are experimental and may not make it but that's how it starts usually. We also know there are AIs that get better results at diagnosing some forms of cancers than most doctors. And collecting trash is typically performed by teams of three people, two to handle the trash cans and one driving the truck. Guess what's likely to happen to the truck driver...
You would have had much better luck mentioning plumbers, electricians and mechanics, all jobs where dexterity, getting into non-standard hard to reach places and solving problems based on incomplete information or trial and error is required. But how many of these jobs do we really need. Can everyone else become a professional football player or singer?
1919: France introduces the 8 hour workday This was met by fierce opposition from DNS-and-BIND:
So, we can't try it out to see if it works, we have to implement it on a massive scale and only then can we know? Yeah, we're not going to experiment with all of society like that. Those kind of social experiments have a bad history of negative outcomes, something that educated people know. Plus you pull out something completely new, that is also untested and unknown? Huh?
So, we can't try it out to see if it works, we have to implement it on a massive scale and only then can we know? Yeah, we're not going to experiment with all of society like that. Those kind of social experiments have a bad history of negative outcomes, something that educated people know. Plus you pull out something completely new, that is also untested and unknown? Huh?
So, we can't try it out to see if it works, we have to implement it on a massive scale and only then can we know? Yeah, we're not going to experiment with all of society like that. Those kind of social experiments have a bad history of negative outcomes, something that educated people know. Plus you pull out something completely new, that is also untested and unknown? Huh?
So, we can't try it out to see if it works, we have to implement it on a massive scale and only then can we know? Yeah, we're not going to experiment with all of society like that. Those kind of social experiments have a bad history of negative outcomes, something that educated people know. Plus you pull out something completely new, that is also untested and unknown? Huh?
The code running in WINE is a mixture of the host platform's ELF or Mach-O binary format and PE/COFF binaries in the Windows ABI, with thunks to go between them.
No. Wine is more than a collection of thunks. There is a lot more than a thunk between a Windows application calling CreateFile() and the C library's open() call. Wine has to bridge completely different APIs: CreateFile() vs. open(), Direct3D vs. OpenGL (or Vulkan/Metal/etc. nowadays), etc. That's not something you can machine-generate or call a "thunk".
Why would it need to? Code using that field will mostly be running in the 32-bit ABI. Only things communicating with the outside world need to be 64-bit and these will access structures via machine-generated thunks.
So what you're proposing is not to implement a layer of thunks between a 32 bit Windows application and a 64 bit Wine, but between a 32 bit Wine and 64 bit native libraries.
You cannot compile code using an ABI. You compile code using a compiler and the compiler used is gcc on Linux (normally) and clang on OSX.
And the compiler targets a specific ABI. Clang (even the Apple builds) can target the 64-bit Apple Mach-O ABI and the 32-bit PE/COFF Windows ABI.
And from that point of view the ABIs match, except on 64 bit OSX where, as I mentioned before, OSX uses a register that Windows applications need left untouched. But as soon as you start mixing bitness the ABIs would no longer match. You'd likely have register issues, but the obvious issues is that any time a native library returns a pointer to you you'd have no guarantee that it would be in the lower 4GB and so your native<->32 bit Wine thunks would have to do much copying.
I have no interest in contributing to WINE since they changed the license though, so someone else will have to do it.
Riiight. The thunking you're proposing would work for any 32 bit application on the platform you develop it for. You wouldn't even have to release it under Wine's license since it would be a completely independent work. But sure, blame Wine's license rather than admit it's hard.
No idea about Linux, but on FreeBSD we do exactly that. For the project that I work on, we machine-generate all of these thunks for 128-bit pointers as well. We also handle ioctls, which have a really horrible design (type information is severely lacking and the values are passed by opaque pointers).
Kernel APIs are small compared to the range of userland APIs that Wine uses.
Code running inside WINE is compiled using the Visual Studio ABI
You cannot compile code using an ABI. You compile code using a compiler and the compiler used is gcc on Linux (normally) and clang on OSX.
which is different in a lot of ways (including the size of long on Win64) to the host environment
This is handled in Wine's C headers. But as mentioned before regular compilers are used so in 64 bit Wine sizeof(long) is 8 (as required by the native libraries that Wine uses), and sizeof(LONG) is 4. So no. No magic! On careful coding.
[...] When a process all of its libraries, stacks and heap are all mapped into the bottom 4GB of the address space, any 32-bit pointer inside the WINE environment can be trivially zero extended to 64 bits when being passed to other code.
Trivially zero-extended or not, code like psecurity_attribute->lpSecurityDescriptor will have to be rewritten because lpSecurityDescriptor is a 64 bit pointer but the psecurity_attribute structure coming in from the application only contains a 32 bit field. If you think going through 1 million lines to fix all such instances is a week-end project then please by all means feel free to send your patch on monday!
You will need thunks, but these can be machine generated in all except a few cases - that's what most operating systems do at the system call layer in for running 32-bit binaries on top of a 64-bit kernel already.
I don't think anyone here can talk for Windows, but as far as I know the Linux kernel does not use "machine generated" code to handle thunking from 32 bit applications. Also the Linux kernel ABI is ridiculously small compared to the Windows userland API. And I'd like to see efficient thunking when the parameter you get is a pointer to a structure with pointers to other structs with pointers... The Windows API sucks in this way. but yes, _some_ can be generated automatically (but will then likely have to be maintained by hand).
That said, I mentioned that there are attempts afoot to handle this anyway. The idea is to only restrict this 32 <-> 64 bit insanity to the lowest level Windows dlls, that is ntdll, ws2_32, directx, opengl, etc. Anything above that that does not interface with native libraries, kernel32, shell32, mshtml, etc, would be compiled as 32 bit dlls. Any high level dll that accidentally uses native APIs (like malloc()) would have to be fixed to only use Win32 APIs. That limits the scope of the problem a bit but still does not make it easy in any way.
In fairness though, any apps that are still 32-bit were probably written for much older hardware and would probably run without much difficulty with the additional pointer work.
Essentially 100% of current 64 bit Windows applications use a 32 bit installer. That's because the 32 bit installer can then show a nice dialog to people trying to run it on a 32 bit Windows telling them they've got the wrong version. The exact same has happened before with the switch from 16 bit Windows to 32 bit Windows: for a decade afterwards all installers were still 16 bit so they could tell people to get Windows 95 or greater.
This assumes you can implement a 32 bit Linux application, one that uses 32 bit pointers throughout, on top of the 64 bit system kernel ABI, 64 bit C library, 64 bit X11 library, 64 bit OpenGL library, etc. Assuming that's even possible, which I doubt, that's really not much better!
Although since we were talking about the Mac, X11 and OpenGL would in this case be replaced with 64 bit Carbon, 64 bit CoreAudio, 64 bit Metal, etc.
Having a 64 bit Wine handle 32 bit Windows applications means converting pointer sizes on the way in and again on the way out
That's true, but in and out of what?
Between the 64 bit Wine code implementing the Win32 API and the Windows application calling it.
For instance take the CreateProcess() [microsoft.com] API.
And most of its implementation in WINE is in a PE/COFF binary that will be compiled in 32-bit mode. Only things that call system libraries will need translation.
This assumes you can implement a 32 bit Linux application, one that uses 32 bit pointers throughout, on top of the 64 bit system kernel ABI, 64 bit C library, 64 bit X11 library, 64 bit OpenGL library, etc. Assuming that's even possible, which I doubt, that's really not much better!
Cruise control maintains your speed extremely well and doesn't ever fail catastrophically.
In the same situation cruise control would have sent the car straight into the obstacle without ever breaking. In fact that's exactly what it did. The only case where cruise control "doesn't fail catastrophically" is when the driver pays attention to the road and takes over when necessary. Precisely what would have saved this driver.
There's actually only one 32-bit application that I do care about: WINE. There's no reason that WINE couldn't be made to launch 32-bit Windows apps as a 64-bit binary though: it already includes its own program launcher and thunks for calling from Windows libraries into host-system ones.
Having a 64 bit Wine handle 32 bit Windows applications means converting pointer sizes on the way in and again on the way out. For instance take the CreateProcess() API. It takes no fewer than 7 pointers as parameters. Not only that but 3 of those point to structures that themselves contain at least one pointer to another structure. Also every time an API returns a pointer to some data, Wine would have to ensure that pointer fits into the 4 GB address space of the 32 bit Windows process. And then you have callbacks.
For a lot of these issues you cannot just automatically generate the thunking code either. And with over 80 000 APIs, not counting COM APIs, and not counting Windows messages (e.g. WM_CREATE comes with a pointer to a structure which itself contains 3 other pointers) you have literally tens of thousands of reasons why WINE can't be made to launch 32-bit Windows apps as a 64-bit binary without a huge undertaking.
Oh. And on OSX Apple also decided to overwrites a CPU register that Win64 applications expect to remain untouched. If I remember correctly, as a result support for 64 bit Windows applications assumes they will only use TEB slots that happen to not be used by OSX and Apple neither confirmed nor denied that this would remain that way, meaning Wine's 64 bit support is already hanging by a thread on OSX.
Despite these obstacles there's already pretty clever exploratory work towards running 32 bit Windows applications in 64 bit processes. But those are still a long way off and it's not yet clear if they will be viable yet.
Really, not only has Wine a huge task ahead of it reimplementing the Win32 API, but it also has to deal with all sorts of crap from Microsoft competitors: Apple not lifting one finger to help with 64 bit support, Apple dropping 32 bit support, Apple letting OpenGL just die, Debian having shitty multiarch support, Linux distributions talking about dropping 32 bit support, Nvidia and AMD producing crappy Linux and OSX GPU drivers. With all these obstacles it's a miracle Wine has gone as far as it has. And in the meantime everyone, governments included, depends on a single supplier, Microsoft, to run all their in-house (Windows) applications.
Slashdot Mirror
Maybe but the big problem is Google does WAY more than just look at traces. They employ sophisticated machine learning techniques to deduce data automatically from images, like automatically reading address bars on buildings.
They are not the only ones doing that. Mapillary is another that uses deep learning to process street-view images and extract important features.
Couldn't there be mobile apps we would run on our phones that relied on Google Maps for navigation but shared our travel experiences to Open Street Map. I wouldn't mind running an app like that for awhile.
You're in luck, there are multiple applications you can run on your phone what will help OpenStreetMap:
StreetComplete - Lets you fill in missing map details for things around you as you walk in the street.
Mapillary - Provides street-view images for OpenStreetMap.
OpenStreetCam - Provides street-view images for OpenStreetMap.
Regarding street-view, Mapillary is the more advanced of the two right now, at least in terms of coverage but also, as far as I can tell, with regards to what they can do with the images. Through deep learning they are now able to recognize street signs, traffic lights, urban furniture, generate 3D building models, etc. And you are allowed to use all this to contribute to OpenStreetMap.
OSM is what YOU make it, too bad you aren't contributing anything but complaints.
Yep. Don't ask what OpenStreetMap can do for you. Ask what you can do for OpenStreetMap.
It's no coincidence that all the places of interest to me are on OpenStreetMap.
The license allows for the data to be taken and incorporated in proprietary software. I assume that GPL proponents would have a problem with that, otherwise I think they would argue for BSD or MIT style licenses instead.
Since the ODBL license terms are essentially the same as the LGPL I don't see why GPL proponents would have a problem with them: you can include LGPL code (resp. ODBL database) in proprietary software as long as you distribute the source for the LGPL code (resp. ODBL database) you used. The ODBL has an additional requirement: attribution.
How about a random stock from the S&P 500?
***USUALLY***
You mean you have never put a new yearly registration sticker on your plate for the last 17 years?!?
Nope. And I didn't even change the license plate when I bought my car. Instead I just filed the paperwork so that the records show the car with this license plate is mine (and any fines go to me (but I didn't get to verify this part yet ;-)). Oh, and in my country registration stickers went out of favor a couple of decades ago. And the stickers that indicate the car is insured and has been inspected for safety are behind the windshield. This also ensures miscreants cannot tamper with them. See? There's a solution to everything!
This sounds like a huge undertaking, and seems to be a smart move but it is daunting to think of the effort involved in changing a national alphabet. I am not sure I've ever heard of such an effort before, anyone else ??
Meh. Sounds much easier than switching the US to metric!
The OP, me, suggested putting one (1) "No Thru Traffic" sign on that one (1) street.
Then you, Ol Olsoc, replied talking about "Not a through street" signs. Now you, Ol Olsoc, have the gall to claim that the OP, me, is confusing "Not a through street" signs with "No Thru Traffic" ones! Not only that but you're trying to muddy things up by making ludricous assertions like claiming "So the solution is to put up signs at every intersection".
The only conclusion is that you, Ol Olsoc, are a troll whose only goal is to derail the discussion.
So the solution is to put up signs at every intersection and implement bogus "Not a through street" zones.
And Ol Olsoc then wrote:
Someone back in this post decided that all we needed to do was make all of the street in communities "No Through Traffic"
That someone being you (and why you made that non-sensical suggestion eludes everybody else). Memory problems?
It's in the PDF of the lawsuit https://d3n8a8pro7vhmx.cloudfr...
Thanks. Unfortunately that councilman's is as vague in this letter as in his previous declarations. It would have been nice to know what "new traffic signage" they tried, for how long, what reasons, if any, Waze and others gave to not take it into account, etc. As it is this councilman seems like all he wants is show the people he's trying to garner votes by flailing uselessly.
So your point is that in order to keep these speeders off my street, I have to break the law to leave my house. If every street in my neighborhood was illegal to use as a street to get somewhere else, we'd all be trapped.
[...]
One way in, one way out, no deviation allowed. The solution is worse than the problem.
Please relinquish your driver license. No through traffic signs have been in existence for decades and you should have learned all about them when getting your driving license. That you are so baffled by them means you have forgotten the basics and are no longer fit to drive.
So the solution is to put up signs at every intersection and implement bogus "Not a through street" zones.
The signs are not bogus if they are put up by the official traffic department. And the traffic department has no more reason to put them at every intersection than for any other sign.
That's already been tried. Waze didn't respond.
LADOT has tried mitigation strategies such as new traffic signage, but this congestion starts and ends with wayfinding technology.
Source? Neither the article nor any of the pages it points to mentions any traffic signage change. How long did they give Waze to update their map? 24 hours?
What? There's got to be over ten thousand miles of local streets that Waze is helping drivers abuse. You can't just make them all "no thru traffic"!
Fortunately there's no reason to stop people using Waze from taking most of those streets.
The solution is really simple. Mark the street as "No Thru Traffic" since that's essentially what he wants. Waze and others will update their maps accordingly. In OpenStreetMap it's just a matter of adding an "access=destination" attribute and I'm sure Waze, Google, Apple and others have similarly simple ways of representing this. They will then stop routing people through that street. The city does no even need to enforce the street sign since all they want to avoid is the excess traffic driven by the apps. Problem solved.
But only the city (or maybe some county/state department) has the authority to make that decision so he should work on it instead of making an ass of himself and wasting everyone else's time.
Who is designing that self-driving truck that can pick up trash cans automatically? That would be quite a feat.
In most countries trash cans are standardized which simplifies their collection quite a bit. I really don't see what would be so hard to automate about it. Not for tomorrow but in a 5 to 10 years. The only thing missing would be collecting overflowing refuse that's been left next to the trash can. But that means out of a team of three you would need at most one employee.
And don't point me to some youtube video of some self driving truck on a closed course picking up trash cans. That ain't reality.
It's called a prototype and is the step just before deployment. You're the one who's refusing to see that reality is changing.
What type of magical "automation" is coming that is going to massively replace jobs? People keep talking about "automation", but is there some magic technology coming that is going to automate out waiters and lawyers and doctors and trash collectors?
There are already restaurants in Japan with robots doing some of the tasks traditionally performed by waiters. Sure those are experimental and may not make it but that's how it starts usually. We also know there are AIs that get better results at diagnosing some forms of cancers than most doctors. And collecting trash is typically performed by teams of three people, two to handle the trash cans and one driving the truck. Guess what's likely to happen to the truck driver...
You would have had much better luck mentioning plumbers, electricians and mechanics, all jobs where dexterity, getting into non-standard hard to reach places and solving problems based on incomplete information or trial and error is required. But how many of these jobs do we really need. Can everyone else become a professional football player or singer?
1919: France introduces the 8 hour workday
This was met by fierce opposition from DNS-and-BIND:
So, we can't try it out to see if it works, we have to implement it on a massive scale and only then can we know? Yeah, we're not going to experiment with all of society like that. Those kind of social experiments have a bad history of negative outcomes, something that educated people know. Plus you pull out something completely new, that is also untested and unknown? Huh?
1936: France mandates 12 days of annual paid vacation
DNS-and-BIND was strongly against it:
So, we can't try it out to see if it works, we have to implement it on a massive scale and only then can we know? Yeah, we're not going to experiment with all of society like that. Those kind of social experiments have a bad history of negative outcomes, something that educated people know. Plus you pull out something completely new, that is also untested and unknown? Huh?
1945: France adopts a national health insurance system
This, despite strong opposition from DNS-and-BIND:
So, we can't try it out to see if it works, we have to implement it on a massive scale and only then can we know? Yeah, we're not going to experiment with all of society like that. Those kind of social experiments have a bad history of negative outcomes, something that educated people know. Plus you pull out something completely new, that is also untested and unknown? Huh?
1958: France establishes unemployment benefits
DNS-and-BIND railed the decision:
So, we can't try it out to see if it works, we have to implement it on a massive scale and only then can we know? Yeah, we're not going to experiment with all of society like that. Those kind of social experiments have a bad history of negative outcomes, something that educated people know. Plus you pull out something completely new, that is also untested and unknown? Huh?
The code running in WINE is a mixture of the host platform's ELF or Mach-O binary format and PE/COFF binaries in the Windows ABI, with thunks to go between them.
No. Wine is more than a collection of thunks. There is a lot more than a thunk between a Windows application calling CreateFile() and the C library's open() call. Wine has to bridge completely different APIs: CreateFile() vs. open(), Direct3D vs. OpenGL (or Vulkan/Metal/etc. nowadays), etc. That's not something you can machine-generate or call a "thunk".
Why would it need to? Code using that field will mostly be running in the 32-bit ABI. Only things communicating with the outside world need to be 64-bit and these will access structures via machine-generated thunks.
So what you're proposing is not to implement a layer of thunks between a 32 bit Windows application and a 64 bit Wine, but between a 32 bit Wine and 64 bit native libraries.
You cannot compile code using an ABI. You compile code using a compiler and the compiler used is gcc on Linux (normally) and clang on OSX.
And the compiler targets a specific ABI. Clang (even the Apple builds) can target the 64-bit Apple Mach-O ABI and the 32-bit PE/COFF Windows ABI.
And from that point of view the ABIs match, except on 64 bit OSX where, as I mentioned before, OSX uses a register that Windows applications need left untouched. But as soon as you start mixing bitness the ABIs would no longer match. You'd likely have register issues, but the obvious issues is that any time a native library returns a pointer to you you'd have no guarantee that it would be in the lower 4GB and so your native<->32 bit Wine thunks would have to do much copying.
I have no interest in contributing to WINE since they changed the license though, so someone else will have to do it.
Riiight. The thunking you're proposing would work for any 32 bit application on the platform you develop it for. You wouldn't even have to release it under Wine's license since it would be a completely independent work. But sure, blame Wine's license rather than admit it's hard.
No idea about Linux, but on FreeBSD we do exactly that. For the project that I work on, we machine-generate all of these thunks for 128-bit pointers as well. We also handle ioctls, which have a really horrible design (type information is severely lacking and the values are passed by opaque pointers).
Kernel APIs are small compared to the range of userland APIs that Wine uses.
Code running inside WINE is compiled using the Visual Studio ABI
You cannot compile code using an ABI. You compile code using a compiler and the compiler used is gcc on Linux (normally) and clang on OSX.
which is different in a lot of ways (including the size of long on Win64) to the host environment
This is handled in Wine's C headers. But as mentioned before regular compilers are used so in 64 bit Wine sizeof(long) is 8 (as required by the native libraries that Wine uses), and sizeof(LONG) is 4. So no. No magic! On careful coding.
[...] When a process all of its libraries, stacks and heap are all mapped into the bottom 4GB of the address space, any 32-bit pointer inside the WINE environment can be trivially zero extended to 64 bits when being passed to other code.
Trivially zero-extended or not, code like psecurity_attribute->lpSecurityDescriptor will have to be rewritten because lpSecurityDescriptor is a 64 bit pointer but the psecurity_attribute structure coming in from the application only contains a 32 bit field. If you think going through 1 million lines to fix all such instances is a week-end project then please by all means feel free to send your patch on monday!
You will need thunks, but these can be machine generated in all except a few cases - that's what most operating systems do at the system call layer in for running 32-bit binaries on top of a 64-bit kernel already.
I don't think anyone here can talk for Windows, but as far as I know the Linux kernel does not use "machine generated" code to handle thunking from 32 bit applications. Also the Linux kernel ABI is ridiculously small compared to the Windows userland API. And I'd like to see efficient thunking when the parameter you get is a pointer to a structure with pointers to other structs with pointers... The Windows API sucks in this way. but yes, _some_ can be generated automatically (but will then likely have to be maintained by hand).
That said, I mentioned that there are attempts afoot to handle this anyway. The idea is to only restrict this 32 <-> 64 bit insanity to the lowest level Windows dlls, that is ntdll, ws2_32, directx, opengl, etc. Anything above that that does not interface with native libraries, kernel32, shell32, mshtml, etc, would be compiled as 32 bit dlls. Any high level dll that accidentally uses native APIs (like malloc()) would have to be fixed to only use Win32 APIs. That limits the scope of the problem a bit but still does not make it easy in any way.
In fairness though, any apps that are still 32-bit were probably written for much older hardware and would probably run without much difficulty with the additional pointer work.
Essentially 100% of current 64 bit Windows applications use a 32 bit installer. That's because the 32 bit installer can then show a nice dialog to people trying to run it on a 32 bit Windows telling them they've got the wrong version. The exact same has happened before with the switch from 16 bit Windows to 32 bit Windows: for a decade afterwards all installers were still 16 bit so they could tell people to get Windows 95 or greater.
This assumes you can implement a 32 bit Linux application, one that uses 32 bit pointers throughout, on top of the 64 bit system kernel ABI, 64 bit C library, 64 bit X11 library, 64 bit OpenGL library, etc. Assuming that's even possible, which I doubt, that's really not much better!
Although since we were talking about the Mac, X11 and OpenGL would in this case be replaced with 64 bit Carbon, 64 bit CoreAudio, 64 bit Metal, etc.
Having a 64 bit Wine handle 32 bit Windows applications means converting pointer sizes on the way in and again on the way out
That's true, but in and out of what?
Between the 64 bit Wine code implementing the Win32 API and the Windows application calling it.
For instance take the CreateProcess() [microsoft.com] API.
And most of its implementation in WINE is in a PE/COFF binary that will be compiled in 32-bit mode. Only things that call system libraries will need translation.
This assumes you can implement a 32 bit Linux application, one that uses 32 bit pointers throughout, on top of the 64 bit system kernel ABI, 64 bit C library, 64 bit X11 library, 64 bit OpenGL library, etc. Assuming that's even possible, which I doubt, that's really not much better!
Cruise control maintains your speed extremely well and doesn't ever fail catastrophically.
In the same situation cruise control would have sent the car straight into the obstacle without ever breaking. In fact that's exactly what it did. The only case where cruise control "doesn't fail catastrophically" is when the driver pays attention to the road and takes over when necessary. Precisely what would have saved this driver.
There's actually only one 32-bit application that I do care about: WINE. There's no reason that WINE couldn't be made to launch 32-bit Windows apps as a 64-bit binary though: it already includes its own program launcher and thunks for calling from Windows libraries into host-system ones.
Having a 64 bit Wine handle 32 bit Windows applications means converting pointer sizes on the way in and again on the way out. For instance take the CreateProcess() API. It takes no fewer than 7 pointers as parameters. Not only that but 3 of those point to structures that themselves contain at least one pointer to another structure. Also every time an API returns a pointer to some data, Wine would have to ensure that pointer fits into the 4 GB address space of the 32 bit Windows process. And then you have callbacks.
For a lot of these issues you cannot just automatically generate the thunking code either. And with over 80 000 APIs, not counting COM APIs, and not counting Windows messages (e.g. WM_CREATE comes with a pointer to a structure which itself contains 3 other pointers) you have literally tens of thousands of reasons why WINE can't be made to launch 32-bit Windows apps as a 64-bit binary without a huge undertaking.
Oh. And on OSX Apple also decided to overwrites a CPU register that Win64 applications expect to remain untouched. If I remember correctly, as a result support for 64 bit Windows applications assumes they will only use TEB slots that happen to not be used by OSX and Apple neither confirmed nor denied that this would remain that way, meaning Wine's 64 bit support is already hanging by a thread on OSX.
Despite these obstacles there's already pretty clever exploratory work towards running 32 bit Windows applications in 64 bit processes. But those are still a long way off and it's not yet clear if they will be viable yet.
Really, not only has Wine a huge task ahead of it reimplementing the Win32 API, but it also has to deal with all sorts of crap from Microsoft competitors: Apple not lifting one finger to help with 64 bit support, Apple dropping 32 bit support, Apple letting OpenGL just die, Debian having shitty multiarch support, Linux distributions talking about dropping 32 bit support, Nvidia and AMD producing crappy Linux and OSX GPU drivers. With all these obstacles it's a miracle Wine has gone as far as it has. And in the meantime everyone, governments included, depends on a single supplier, Microsoft, to run all their in-house (Windows) applications.