Microsoft's saucy compiler exposes privates to devs Microsoft has delivered early code for its "compiler-as-a-service" project for Visual Basic and C#, which lets developers hook into the software building process. Codenamed Roslyn, the project involved Microsoft completely rewriting the existing compilers for Visual Basic and C# from C++ to native Visual Basic and C#, …
And "If I resize a dialog box then bloody remember that for next time".
My biggest pet peeve I think is automatic highlighting of a file in the solution. Most of the time it's very useful especially with solutions that have several projects. But it means with C++ that if you try to bring up the project options it will show them then immediately replace them with the options for the current source file as the IDE goes back to highlighting that in the solution.
Then there's the tabs in the editor. Its logic for moving them out when it gets crowded is stupid. If it was me I'd push out the one that had been looked at longest ago. But no - it seems to just push out the right most tab. Even if that was the last file you looked at prior to opening a new one. They could also consider doing what Borland did - combine CPP and H onto one tab and allow the user to toggle without changing tabs.
Mine's the one with the list of complaints in the pocket.
Is this me, or does this remind others of Niklaus Wirth's (failed) attempt to write a Pascal compiler in FORTRAN?
Or are they just modifying the compiler to make interim listings available in C# and Visual Basic showing the transformations performed by the code optimizer (in much the same way as the Cray FORTRAN and C compilers I used in the 90s?
What’s you issue with this banjomike? Anybody can access the machine code, all as you have to do is look at whatever file the compiler has created to look at the machine code and disassemble it. No big secrets there.
In fact writing your own compiler capable of simple syntax checking is relatively simple, all you need is the a BNF description of the language and programs like LEX and YACC to create a basic parser for the language.
It looks like to me that all mickeysoft have done is make the parse trees available inside studio.
Are you and your friend both complete halfwits? The article talks about a compiler that appears to allow the developer (read hacker or other nogood) to see what is happening inside the compilation process which has been hidden from all but the most intelligent and diligent developers probably for the entire lifetime of computers. Now suddenly all this hidden info, whatever the hell it is, will be visible (read hackable) and "expose this conversion process, thereby making it possible for those outside Microsoft to see what's happening ". Tell me that this will not assist hackers and other malware persons. These people have had no great problems in covering the PC world with spam, trojans, viruses, worms and god knows what else. This new compiler can only help them.
This "hidden info" is about the way your code is translated by the compiler into assembly and machine code.
I can already go read that if I so choose but it's a massive pain in the arse to do so. Microsoft will simply be making that easier for me.
This won't help anyone to write malware, except in so far as malware is a form of program and it will help programmers to write more efficient programs.
Your argument here appears to be that anything which makes programming more efficient will lead to more efficient malware. Well, maybe so but you could say that about IDEs or libraries or books about best coding practise.
"We shouldn't make writing software better because some people might write bad software". Are you suggesting a government licensing scheme? or simple removing all programming tolls so that we go back to hand coding in text files?
Please, explain to me what you want here. This is like inventing a more fuel-efficient car and having somebody complain about road safety.
"see what is happening inside the compilation process which has been hidden from all but the most intelligent and diligent developers probably for the entire lifetime of computers"
Many, many people understand how compilers work. It's not black magic. And for much of "the entire lifetime of [digital electronic] computers", many to most developers worked in assembly anyway. We still see a lot of commercial mainframe applications with numerous assembly modules - and these are *apps*, not system software.
And since Microsoft's compilers, like most, will on request generate mixed source-and-assembly listings, anyone using them can see line-by-line results of that mysterious compilation process already.
Nor is Microsoft the first to provide an API for driving their compiler stack. There are the dynamic languages, going back to LISP and its eval operator, from the mid-1960s. There are languages designed for embedding and runtime compilation, such as Lua. And there are other instances where vendors have simply provided a procedural interface to a compiler, like the CRTMIPGM() API for IBM's OS/400, circa 1990.
The big news here isn't that Microsoft's providing "visibility" into the compiler; it's that they've provided APIs for various compilation stages, primarily to make it easier to hook more tools into the compiler. That's not new either; other compiler vendors have done it in the past.
"Tell me that this will not assist hackers and other malware persons."
It will not assist hackers and other malware persons. Anyone bright enough to understand how to use the compiler APIs will already know anything they could learn from them.
A typical compiler consists of several programs that are run one after the other, each program performing one stage of the process -- preprocessor, tokenizer, lexical analysis &tc. Most people don't notice this, they just use a top level program such as 'cl' or 'gcc' to start the process off. In theory there's nothing stopping you from interacting with any of these programs but typically the only one that you look at the output of is the preprocessor to see what happened to all of those defines and preprocessor directives.
IDEs are fine things, they're very useful, but all they do is run the tools for you. We've been using them for so long that we seem to have lost touch with the underlying tools.
The front-end of a compiler parses the source code, pulls in references and creates an internal representation of the program. Then various programs can manipulate the internal representation, adding safety checks, performing general improvements, before the target-architecture-specific backend generates the binary code, while doing architecture-specific changes.
Other compilers have exposed this for a long time, and we see some third-party tools pop up as a result; it's reasonable for MS to want to encourage some of that development work to happen in their compiler tools, rather than being _forced_ to go elsewhere -- forcing customers and developers to support the competition not generally being considered a winning strategy.
Now, a project like gcc-sense providing tab-completion for C programming probably isn't anything new to those using IDEs, but it gives you an idea for some of what people are doing. GCC has traditionally been of the "it must be GPL to plug into GCC" persuasion, which has kept some independent developers away, but they've finally shifted. Perhaps because the Apple-sponsored LLVM compilation infrastructure (with the Clang frontend for C) have spurred competition here, with LLVM IR (Intermediate Representation) and BSDish licensing.
Now that there's GCC and Clang _free_ for the taking, MS pretty much _have_ to open things up to keep any development work happening there and remain relevant.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
