Computing desk
< March 3	<< Feb \| March \| Apr >>	March 5 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

March 4

Disassemble code

When you disassemble code (from machine code with an disassembler) can you know in what language the machine code was originally written? If you apply a decompiler to the assembly, which was disassembled from machine code, would that be a feasible way to read the original code? --Noopolo (talk) 01:41, 4 March 2015 (UTC)[reply]

In the general case, no to both. If your executable is not stripped, a good disassembler may be able to access the symbol table and use symbolic labels. These symbols can give clues to the language or at least the language family. With enough experience, you might also be able to detect tell-tale patterns. Lisp will produce code that is different from normal C code, and C++ code will often have indirections for calling overloaded functions. But this is not obvious, and not necessary - historically, some compilers even compiled Lisp, C++, and other languages to C first, and used the C compiler for the final step. Decompilers typically rely on the known idiosyncrasies of the source language and the original compiler - if these are unknown, decompiling will be very hard indeed, and the quality of the code will probably be very bad. --Stephan Schulz (talk) 02:07, 4 March 2015 (UTC)[reply]

In that symbol table, there may be much to be inferred from the name mangling scheme used. In languages like C++, where the name mangling scheme isn't standardised, the style of mangling hints at which compiler was used. -- Finlay McWalterᚠTalk 11:35, 4 March 2015 (UTC)[reply]

(ec) This depends very much on the source language and the options used to compile it. Languages such as Java and C#, which target high-level virtual machines, can often be decompiled into fairly readable code. Low-level languages, such as C and C++, not so much.

Supposing that we're talking about native-compiled code here, the disassembly might not help very much but you can almost certainly work out which compiler was used from the symbol table, supposing the executable hasn't been stripped. Exactly how you get this depends on your operating system; for instance, objdump -T /bin/ls on an Ubuntu 14.04 system throws up this symbol:

     0000000000000000  w   D  *UND*	0000000000000000              __gmon_start__

This is the entry routine for GProf-based profiling and is inserted by GCC into executables.

~~If anyone knows of a better template for formatting code, please feel free.~~ GoldenRing (talk) 02:13, 4 March 2015 (UTC)[reply]

Do you mean something like this?

    0000000000000000  w   D  *UND*	0000000000000000              __gmon_start__

Result obtained by spaces at the beginning of a line. --CiaPan (talk) 09:29, 4 March 2015 (UTC)[reply]

The very one. You live and learn. GoldenRing (talk) 23:00, 4 March 2015 (UTC)[reply]

Most programs call the language's standard runtime language using a shared library (DLL, etc). The name of this will indicate which language the program was written in. If the runtime library was statically linked, then heuristics can be used. The presence of arrays of pointers to functions would hint at vtables being used. This is indicative of an object orinated language being used, rather than a procedural language. In MS-Windows, the register ECX contains the this pointer. If the start of the area pointed to by ECX is a pointer to a vtable, then it almost certainly is an object-orinatited language. The layout of the vtable may give hints about the source language and compiler used. C/Pascal calling convention and string layout may also give further hints. Otherwise, searching for known characteristics of the statically linked library will tell you the source language, standard library version, and probably the compiler as well. LongHairedFop (talk) 11:15, 4 March 2015 (UTC)[reply]

Skype logging in to Microsoft account

The last few days my Skype has been logging in automatically to my Microsoft account, and not my Skype account. This only happens on the Windows PC, but not on my Mac or Linux or Android. Is there any way to stop it doing this? I want to login using my Skype address, beacuse that is the one I use for work. KägeTorä - (^影_虎) (Chin Wag) 08:48, 4 March 2015 (UTC)[reply]

Just redownloaded it. No worries. KägeTorä - (^影_虎) (Chin Wag) 18:36, 4 March 2015 (UTC)[reply]

Resolved

Some software doesn't grasp my Windows 8 screen resolution.

I'm really sorry if this has been addressed here; I didn't find anything with a search but I might not have used the proper terminology.

My Acer laptop with Windows 8 is working pretty well but I have two instances of software that doesn't seem to know what my screen resolution is. (My actual resolution is 2560x1440.)

1) When Google Earth fires up it pops up a complaint that "Your desktop resolution is set to smaller than 1024x768. Google Earth requires a resolution of at least 1025x768 to be viewed properly. The application will run, however the layout may not be optimal." Actually, once it gets going it's fine.

2) Much more bothersome is the case of ArcGIS, which scales its menu bar options ('File', 'Edit', etc.) about 0.5 mm high; I think because it thinks that I have a huge high resolution screen. It's very very hard to read.

Everything else I run - Google Chrome, etc. - is fine.

So what's to blame? What should I do?

Hayttom 16:06, 4 March 2015 (UTC) — Preceding unsigned comment added by Hayttom (talk • contribs) [reply]

(I took the liberty of numbering your cases.)

1) I suspect that Google Earth checks to see if you have any resolution it recognizes, and, if it doesn't, it gives that warning message. That's probably appropriate, given that they haven't actually tested with your resolution, although they shouldn't have assumed that any resolution they don't recognize is smaller than 1024×768.

2) In the case of ArcGIS, it sounds like the problem is that it's not scaling up to use the high resolution. This is a common problem. As we get screens with smaller and smaller pixels, we need the software to use more pixels when displaying text, so the text will stay the same physical size. I have many applications where the text is tiny because they failed to do this. The obvious solution is to use a lower resolution, or perhaps a magnifier program that zooms in on text as you move the mouse over it or magnifies the whole screen. (And no, magnifying the whole screen isn't the same as just using a lower resolution, because it only displays a portion of the screen at a time, but magnified.) There is also an option in Windows to use larger text, but I've found it doesn't work well at all. Only some text is adjusted, and it's often then truncated, because it no longer fits in the text box, window, etc. Maybe they've fixed this in Windows 8, but I doubt it. (If you need help to adjust any of these settings, just ask us.) StuRat (talk) 17:24, 4 March 2015 (UTC)[reply]

I suspect that Windows is reporting a screen resolution of 1280×720 to Google Earth, and then scaling everything by 2, because it doesn't identify itself as dpi-aware. See [1]. Are you using the latest version of Google Earth? There were apparently some changes to high-DPI behavior in Windows 8.1 ([2]), which was released at about the same time as the most recent version of Google Earth. Maybe that Google Earth release fixed Windows 8.1 compatibility, or maybe that won't happen until the next release.

You might be able to solve the problem with ArcGIS by unchecking "Disable display scaling" in the Compatibility tab of the shortcut properties, if it's checked. -- BenRG (talk) 19:37, 4 March 2015 (UTC)[reply]

1) I will investigate versions this weekend.

2) WOW! I solved the problem by CHECKING "Disable display scaling"! Thank you very much!

Hayttom 01:24, 5 March 2015 (UTC)[reply]

I've been using a non standard DPI setting with various displays for various reasons for a long time. I can say support for scaling in non MS apps remains fairly poor. The new APIs may help, but I think the bigger thing is most developers simply didn't bother because they didn't regard it as important. From what I've seen, this is finally getting attention thanks to the proliferation of higher resolution displays, but it's still slow progress. Nil Einne (talk) 17:07, 5 March 2015 (UTC)[reply]

Chrome update

Referring to this question, it appears whatever the problem is, it is unique to the library where I was last week. The library where I can use Firefox was closed. I haven't asked for the results of any investigation.— Vchimpanzee • talk • contributions • 16:22, 4 March 2015 (UTC)[reply]

Creating simple animations with .svg files and line drawings

What is the best way to create simple animations of line drawings, text, and .svg files with zoom, pan, and fade, synced to a pre-existing voiceover track on Windows 7 with free software? I was using something originally for Linux called Tuvi but it keeps refusing to open saved project files, causing lots of lost work. Thanks! 184.96.139.187 (talk) 20:45, 4 March 2015 (UTC)[reply]

Update: giving Shotcut a try; advice still very welcome. 184.96.139.187 (talk) 22:32, 4 March 2015 (UTC)[reply]

NOPE. No .svg file tweening. Trying StickPy (no SVG?), Stykz, CreaToon, Synfig, ... etc. Help me out? 184.96.139.187 (talk) 03:44, 5 March 2015 (UTC)[reply]

No actual advice here - but I've been working with SVG animations for the first time over the last few weeks, and I have to say that an alarming proportion of the things that *should* work according to the SVG specification are either unimplemented, buggy or doing different things in Safari, Chrome and Firefox. In at least a couple of cases, browser writers don't agree on what the specification actually means - so deciding which browser has the bug is a non-trivial matter!

I've been generating my SVG animations from my own C++ code - so, unfortunately, I don't have a suggestion for an authoring tool.

Have you tried talking to the authors of Tuvi to see if they can fix the problems you have? Generally, if you can provide a decent test-case (in this example - a project file that won't load), most OpenSource authors are more than happy to try to figure out what went wrong and fix it ASAP. SteveBaker (talk) 21:36, 5 March 2015 (UTC)[reply]