Computing desk
< July 18	<< Jun \| July \| Aug >>	July 20 >

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.

July 19

Online port scanner for my computer

Does anyone know of an online port scanner that is capable of scanning ports 0-65535 all in one go (i.e. all of them)? I just want to thoroughly check my computer's security. Cheers. --Kurt Shaped Box (talk) 11:17, 19 July 2014 (UTC)[reply]

GRC ShieldsUp! do that.. or at least, that is what the page claims. It also checks for other leaks and holes. WegianWarrior (talk) 19:31, 19 July 2014 (UTC)[reply]

Yup - but that one only scans from 0-1056. Those are the standard ports, but there are more. I believe that you can enter the higher numbers in a custom scan, but only 64 at a time. There did used to be a site that did what I was looking for - the scan took about 10/15 minutes. I don't know if it's gone from the internet now though... --Kurt Shaped Box (talk) 08:23, 20 July 2014 (UTC)[reply]

These sites, [1], [2], [3] all appear to do what you are looking for. This site [4] asks you to only do a range of 500, but it looks like it may do more (I did not test it, only including it in the event that the others all fail to satisfy, you still have an option).Phoenixia1177 (talk) 03:33, 21 July 2014 (UTC)[reply]

Not as good as an external scan, obviously, but if you're familiar enough with a C++ compiler and the linking process you can at least scan your own ports internally with this simple program (to fine-tune things like timeout settings, you can pass probe.handle() to standard socket API functions):

[you'll need this header file]

#include <ip.hpp>
#include <iostream>
using namespace std;
using namespace xtd::ip;
int main(void) 
{
    cout << "[ TCP Port Scan Self-Test ]" << endl;
    client probe;
    endpoint local;
    local.address = "127.0.0.1";
    local.protocol = IPPROTO_TCP;
    for(local.port = 0; local.port < (1 << 16); ++local.port)
    {
        if(probe.open(local))
            cout << "Listening: ";
        else
            cout << "No Response: ";
        cout << local.port << endl;
    }    
}

Sebastian Garth (talk) 10:05, 22 July 2014 (UTC)[reply]

Concurrent programming languages and non-concurrent programming languages

What makes a programming language non-concurrent? Can't all languages start a process, a second process and so on? (in the same way that a user can start several programs). OsmanRF34 (talk) 12:36, 19 July 2014 (UTC)[reply]

It may be instructive to turn the question around and ask "what makes a programming language concurrent ?". Some languages provide native support for a concurrent programming paradigm. This is not just the ability to start new processes, but also involves a model for communicating between processes and handling interrupts. Other languages require an extension, add-on or library to support concurrent programming. This creates an additional learning overhead for the programmer, and may be less efficient (slower running, more memory overheads etc.) than a language that provides native support. Gandalf61 (talk) 13:53, 19 July 2014 (UTC)[reply]

Some languages are designed around concurrency to such an extent that virtually any nontrivial program in that language will make heavy use of it. Erlang and ToonTalk are examples. Others (like Java) are conventional sequential-imperative programming languages that just happen to have standard support for concurrency, and I wouldn't necessarily call those concurrent languages. Wikipedia's Category:Concurrent programming languages seems to be inconsistent about this—it includes Java but not C++11, for example. -- BenRG (talk) 23:01, 19 July 2014 (UTC)[reply]

Are there any languages/compilers that can figure out for themselves what can be optimized into concurrent processes and what can't ? (In some cases, it might need to gather statistics from several typical runs to figure this out, similar to how some relational database systems gather stats and use those to optimize indexing, etc.) StuRat (talk) 04:06, 20 July 2014 (UTC)[reply]

Automatic parallelization is very hard in general. The overhead of creating and synchronizing threads is large enough that you need to do a fairly large amount of independent computation in each one before it pays for itself, and most programs don't have such long independent computational chains in them, at least not without high-level algorithmic changes that compilers aren't smart enough to do automatically. Automatic vectorization, using SIMD instructions instead of threads, is much easier and a lot of popular optimizing compilers support it. (Historically this was a strength of Fortran compilers, but I think the C++ compilers have caught up.) -- BenRG (talk) 05:56, 20 July 2014 (UTC)[reply]

Thanks. StuRat (talk) 12:13, 20 July 2014 (UTC)[reply]

simple cross-platform library to display rasters?

I have a C program that runs a simulation and outputs the final state as a PGM raster image, but I want to make it display rasters for the intermediate states as they're computed. I know almost nothing about graphics libraries. I'm on my way to figuring out how to do what I want with OpenGL and GLFW. But that seems like overkill for such a simple task. If I understand right, the whole point of OpenGL is rendering, and I don't need any rendering. Just a window I can draw pixels on. So what am I missing? Is there a conventional cross-platform way to do what I want? Or do people just use OpenGL, since it exists and works? Thanks! --Allen (talk) 19:18, 19 July 2014 (UTC)[reply]

Graphics libraries take primitives operations like "draw line" and generate image files (or image buffers in memory). They don't display them. It sounds like you don't need the graphics library part at all (you're doing that yourself in your own code). What you need, as you say, is something to make a visible window, provide your program with something to draw into, and manage the usual events that keep a graphical application on Windows, Linux, etc. working okay. That's the job of a GUI toolkit; there are a bunch of cross-platform ones, including wxWidgets, GTK+ and Qt. But these are heavy tools for this simple job you want. For what you want, I'd recommend Simple DirectMedia Layer (SDL). Although SDL is designed for games, it's good for what you want too, and it's super simple to use. I have a program somewhere that draws a Mandelbrot set into an SDL window, with progressive updates as the computation proceeds. I'm pretty sure I used SDL; I'll see if I can dig it up. -- Finlay McWalterᚠTalk 19:32, 19 July 2014 (UTC)[reply]

Thanks Finlay! I'll look into SDL. And it'd be great to see your Mandelbrot code if you do come across it. --Allen (talk) 19:47, 19 July 2014 (UTC)[reply]

It turns out I had some SDL code, and some Mandelbrot code, but they weren't together. So I merged the two to make this very basic example. Note that the flow of this code mostly resembles a conventional non-interative program, and as such it's a bad example of how you'd actually code in any interactive GUI system (whether SDL or another toolkit). Because a program has to respond to inputs and other events, they're typically event driven, where the main event loop never blocks (to keep the program responsive). In such environments, if a program needs to do long-running computation, the calculation is farmed out to a different thread, and care must be taken to properly synchronise (coordinate) access to shared resources. In this case, for simplicity (and laziness) I do just block, which is why the program is totally unresponsive during the calculation; it can't even be closed. -- Finlay McWalterᚠTalk 22:32, 19 July 2014 (UTC)[reply]

I should note that it is possible to do long-running calculations without the complexity of another thread. What one typically does is have the main loop poll for events, and then (if there's no event to service) do just a tiny bit of the calculation (only a few millseconds worth) before going back and polling again. This isn't hard, but it rather everts the flow of control, so it takes a bit of getting used to. -- Finlay McWalterᚠTalk 22:37, 19 July 2014 (UTC)[reply]

This is exactly what I needed; thank you! I'm not worried about interactivity just yet, so blocking is no problem. I'm just happy to know how to put pixels on a window. --Allen (talk) 02:24, 20 July 2014 (UTC)[reply]

I'd like to know the same thing, but from Fortran (specifically gfortran). My current approach is to output an image file and display that, but this is too slow for continuous updates. StuRat (talk) 02:30, 20 July 2014 (UTC)[reply]

In your position, I'd just have the program write out these consecutive intermediate images into a somewhat more common format (PNG, JPEG - using libpng and libjpg respectively) into a directory someplace and write a simple HTML wrapper so you can view your raster images in a browser. The nice thing about doing this stuff there is that the browser takes care of all of the windowing stuff for you. It's really easy to use JavaScript to grab different images and display them consecutively or whatever.

SteveBaker (talk) 03:57, 20 July 2014 (UTC)[reply]

That's exactly what I do now, from Fortran. It takes several seconds to update an image, though, and closing the old image is tricky, requiring you to kill the browser process. I used IE as the browser, since that's likely to be on any Windows PC. StuRat (talk) 04:02, 20 July 2014 (UTC)[reply]

There is a trick to making it reload - I used this to load still frames from a webcam feed - the file "webcamOutput.jpg" gets reloaded about once a second. To prevent the system from caching it, add a garbage "?t=xxx" to the end of the filename and increment xxx each time:

 <html>
 <head>
   <META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">
   <script>
     var unique = 0 ;
     function reloadImage()
     {
       var webcam0 = document.getElementById ( "webcam0" ) ;
       webcam0.src = "webcamOutput.jpg?t=" + unique ;
       unique++ ;
       setTimeout ( "reloadImage()", 1000 ) ;
     }
   </script>
 </head>
 <body>
   <div id="webcamWrapper">
     <img id="webcam0" src="webcamOutput.jpg">
   </div>
   <script>
     reloadImage() ;
   </script>
 </body>
 </html>

should work on any browser. (IE is by *far* the worst browser to choose for this kind of thing!) SteveBaker (talk) 15:38, 20 July 2014 (UTC)[reply]

So changing the title of the image file stops it from reading it from the cache ? Thanks, I might try that. But it still is probably too slow of a refresh rate for many applications. One issue that comes up is image compression. Either I spend the time to compress each image, or I deal with huge files, either of which may slow things down to an unacceptable degree. StuRat (talk) 16:25, 20 July 2014 (UTC)[reply]

Yes - changing the filename WOULD avoid the cache issues - but that's not quite what I'm doing. When the browser requests a file via a URL, it can add parameters to that request (like if you check a box in an online form). If the file (which in this case is a dumb image) has no interest in those parameters, they are ignored...but they serve to make the request unique - even though the file isn't. And that's enough to bypass the cache without you end up with a bazillion junk images on your computer. As for speed. I'm using this to monitor a web cam at one frame per second (or so) - and it's plenty fast enough for that - even grabbing the file over the Internet. However, if you need more speed than that, or if your files are *HUGE* then you're effectively building a full graphical program and/or engineering a video stream and then you'll be writing a LOT more code! However, for monitoring slow-running processes - this is great because you can view it over the network, view it on your phone and the amount of code you need is tiny. So YMMV. SteveBaker (talk) 17:04, 20 July 2014 (UTC)[reply]

My particular application was a redneck version of the board game Clue, featuring characters like "Skeeter" and "Bubba", locations like "The Trailer" and "the Outhouse", and weapons like "Bottle of Jack Daniels" and "Pit Bull". I had a separate text command line interface window, and wanted to also show the game board graphically. So, if I wanted to display (barefoot) foot prints when the player moved, a one second delay would be too slow for each step, with up to 12 steps per move. A tenth of a second would be good, though. I ended up using an animated GIF to get the speed I needed. StuRat (talk) 17:32, 20 July 2014 (UTC)[reply]

OpenGL is supposed to be a general graphics library with support for 2D as well as 3D graphics. If you just want to blit a bitmap into a window without any fancy 3D effects, glDrawPixels will do that efficiently. Here's a complete example doing more or less what you want, though using GLUT rather than GLFW. It's quite similar to Finlay McWalter's SDL code. GLUT doesn't support event polling, so you would have to do your calculation in the glutIdleFunc callback (which could be a hassle because of the control inversion), or else use GLFW which does support polling. -- BenRG (talk) 05:26, 20 July 2014 (UTC)[reply]